← Volver al blog Gobierno de TI

Gobierno de TI: qué es, para qué sirve y cuándo sobra

El gobierno de TI es el conjunto de reglas que define quién decide qué sobre la tecnología de una organización: quién autoriza una compra, quién puede contratar un servicio en la nube sin pedir permiso, quién es dueño de un riesgo cuando se materializa y quién tiene facultad para decir que no. No es un área, no es un software y no es un manual: es un reparto de facultades escrito, con nombres y montos.

Esta guía responde lo que casi nunca se responde: en qué se diferencia de la gestión de TI (la diferencia decide quién firma), cuándo un gobierno de TI vale la pena y cuándo es puro comité, qué son COBIT, ISO/IEC 38500 e ITIL de verdad —y cuál de los tres no es de gobierno—, cómo se implanta en cinco fases con plazos, y los siete errores que lo convierten en burocracia que nadie respeta.

Qué es el gobierno de TI, y qué no es

Gobernar la tecnología es responder tres preguntas por escrito y sostener la respuesta: qué se espera de la tecnología (dirección), quién tiene facultad para comprometer dinero y datos (autoridad) y cómo se comprueba que se cumplió (rendición de cuentas). Todo lo demás —el inventario de servidores, el catálogo de servicios, la mesa de ayuda— es gestión, y ocurre después.

La prueba de que una empresa no tiene gobierno de TI no es que le falte un documento. Es que nadie puede contestar, sin dudar, preguntas como estas:

• ¿Quién autorizó la suscripción que aparece en el estado de cuenta de la tarjeta corporativa y que nadie reconoce?
• Si mañana se filtra la base de clientes, ¿quién responde: el proveedor, sistemas, o la dirección comercial que subió el archivo?
• ¿Quién puede aprobar una excepción a la regla de respaldos, y hasta cuándo dura esa excepción?
• ¿Qué monto puede comprometer el responsable de sistemas sin pasar por dirección?

Cuando las cuatro respuestas existen, están escritas y se respetan, hay gobierno de TI aunque nadie lo llame así. Cuando no existen, no hay gobierno por más comités que se convoquen.

Gobierno o gestión: la diferencia que decide quién firma

Es la confusión más cara del tema, y tiene una consecuencia práctica inmediata: si se confunden, el área de sistemas termina aprobando sus propias decisiones de inversión y auditándose a sí misma.

COBIT 2019 lo formaliza de una manera que sirve incluso si nunca adoptas el marco completo: separa 40 objetivos en cinco dominios. Uno solo es de gobierno —EDM, de Evaluate, Direct and Monitor, con cinco objetivos— y los otros cuatro son de gestión: APO (alinear, planear y organizar, 14 objetivos), BAI (construir, adquirir e implementar, 11), DSS (entregar, dar servicio y soporte, 6) y MEA (monitorear, evaluar y valorar, 4).

El número que importa no es el 40: es el 5. Cinco objetivos de gobierno contra treinta y cinco de gestión. Si en tu empresa el comité de tecnología dedica la reunión a revisar tickets y tiempos de respuesta, está haciendo MEA disfrazado de EDM: gestión con nombre de gobierno.

Cómo se nota la confusión en la práctica

• El responsable de TI presenta y aprueba. Trae la propuesta, la defiende y nadie más tiene criterio para contrastarla. No es mala fe: es que no hay quien ejerza el gobierno.
• Los riesgos tecnológicos viven solo en TI. Si el dueño del riesgo de «no poder facturar tres días» es el jefe de sistemas y no el director de finanzas, el riesgo está mal asignado.
• El presupuesto se discute una vez al año y las decisiones se toman todo el año. Entre presupuesto y presupuesto, cada compra es una decisión de gobierno tomada sin gobierno.

Cuándo vale la pena y cuándo es puro comité

Casi ningún contenido sobre el tema dice esto: hay organizaciones para las que montar una estructura de gobierno de TI es, hoy, sobreingeniería. Distinguir un caso del otro antes de arrancar ahorra meses de reuniones.

Cinco señales de que sí lo necesitas

1. Aparecen servicios contratados que nadie autorizó. El síntoma clásico del shadow IT: suscripciones en la tarjeta corporativa, herramientas contratadas por un área, datos de clientes en plataformas que nunca pasaron por revisión. Es una decisión de gobierno que alguien está tomando sin facultad.
2. El gasto en tecnología crece y nadie puede explicar contra qué. No es un problema de contabilidad: es que no hay criterio de priorización, así que se aprueba lo que llega con más urgencia o con más insistencia.
3. Un cliente, una auditoría o un contrato empezó a preguntar. Los cuestionarios de proveedores, las licitaciones y las cadenas de suministro piden políticas, controles y responsables nombrados. Aquí el gobierno deja de ser higiene interna y pasa a ser acceso a mercado.
4. La operación ya no sobrevive a la ausencia de una persona. Si una sola persona tiene todas las contraseñas de administrador y es la única que sabe cómo se restaura un respaldo, el riesgo no es técnico: es de gobierno.
5. Manejas datos personales de terceros. En México, la protección de datos personales en posesión de particulares exige un responsable identificable, aviso de privacidad y medidas de seguridad. Nada de eso se sostiene sin reglas escritas sobre quién accede a qué.

Cuatro señales de que todavía no

1. Sois pocos y todo pasa por la misma persona. Con un equipo donde el director ve cada compra, el gobierno ya existe de hecho. Lo que falta es escribir dos o tres reglas, no montar un comité.
2. Lo quieres para presentar un organigrama. Un comité que se reúne para llenar un acta produce actas, no decisiones.
3. La dirección no piensa asistir. El gobierno de TI es, por definición, una función de la dirección. Si el director general delega su asiento, lo que queda es un comité técnico sin facultades.
4. Todavía no hay nada que gobernar. Si la tecnología de la empresa son correo, facturación y una hoja de cálculo, el trabajo útil está en ordenar procesos y respaldos, no en diseñar un sistema de gobierno.

Las seis decisiones que un gobierno de TI tiene que resolver

Un sistema de gobierno de TI que funciona no tiene que cubrir cuarenta objetivos. Tiene que dejar resueltas, por escrito, seis decisiones. Si alguna queda sin dueño, ahí es exactamente donde va a aparecer el problema.

1. Quién autoriza el gasto, y hasta qué monto

Una tabla de facultades con tres o cuatro escalones: lo que el responsable de TI aprueba solo, lo que requiere al director del área usuaria, lo que requiere a dirección general y lo que requiere al consejo o a los socios. Sin montos, la tabla es decorativa.

2. Quién puede contratar servicios en la nube y con qué revisión previa

Es la decisión que más se salta, porque contratar una herramienta en línea toma cuatro minutos y una tarjeta. La regla mínima: cualquier servicio que vaya a almacenar datos de clientes, de empleados o información financiera pasa por una revisión de seguridad y por el registro de proveedores, sin importar su costo.

3. Quién es dueño de cada riesgo tecnológico

El dueño de un riesgo es quien sufre la consecuencia, no quien administra el servidor. La caída del sistema de facturación es un riesgo de finanzas; la fuga de la base de prospectos, de comercial. TI opera los controles; el área de negocio acepta o rechaza el riesgo residual. Lo desarrollamos en la guía de gestión de riesgos tecnológicos.

4. Qué se mide y con qué frecuencia se mira

Dos o tres indicadores que la dirección entienda sin traducción: disponibilidad del sistema que factura, tiempo de recuperación probado de un respaldo, número de excepciones vigentes a las políticas. La trampa es medir lo que es fácil de medir —tickets cerrados— en lugar de lo que importa.

5. Cómo se autoriza una excepción, y cuándo caduca

Toda regla se rompe alguna vez por una razón legítima. Un gobierno sano no lo prohíbe: lo documenta. Quién la pide, quién la autoriza, por qué, qué control compensatorio se pone y en qué fecha se revisa. Una excepción sin fecha de caducidad es una política derogada en silencio.

6. Quién decide sobre el uso de inteligencia artificial

Es la decisión nueva, y en la mayoría de las empresas mexicanas ya se está tomando sin permiso: alguien pega información de un cliente en un asistente generativo. Hace falta definir qué datos pueden salir de la organización, qué usos quedan prohibidos y quién revisa una herramienta antes de adoptarla. Está tratado a fondo en políticas de uso responsable de IA y en qué es la gobernanza de IA.

COBIT, ISO/IEC 38500 e ITIL: cuál es cuál

Los tres nombres aparecen juntos en casi todos los artículos del tema, y los tres hacen cosas distintas. Usarlos con precisión es la diferencia entre comprar lo que necesitas y comprar un proyecto de dos años.

A esos tres se suman, según a qué le tengas miedo, normas certificables que cubren un dominio concreto: ISO/IEC 27001:2022 para seguridad de la información, ISO/IEC 20000-1 para gestión de servicios de TI e ISO/IEC 42001 para sistemas de gestión de inteligencia artificial. Son otra cosa: son sistemas de gestión auditables por un tercero, no marcos de gobierno.

La regla para elegir: ISO/IEC 38500 para decidir cómo se gobierna, COBIT para diseñar el detalle, ITIL para operar el servicio, y una norma certificable solo cuando alguien de fuera te la va a exigir.

Lo que se vende como gobierno de TI y no lo es

Esta sección ahorra dinero. Cuatro cosas se venden habitualmente como «gobierno de TI» y ninguna lo es:

1. Una herramienta. No existe software de gobierno de TI, del mismo modo que no existe software de tomar decisiones. Hay herramientas que ayudan a registrar riesgos, activos y excepciones; el gobierno es el criterio, no el registro.
2. La certificación de una persona. Que alguien del equipo tenga una credencial de COBIT es útil y no es gobierno. La facultad de decidir no se certifica: se delega por escrito.
3. Un documento maestro de cuatrocientas páginas. Un marco descargado y adaptado con buscar-y-reemplazar produce un documento que nadie aplica. Lo que se aplica cabe en una tabla de facultades, media docena de políticas y un acta trimestral.
4. La adopción completa de COBIT. COBIT 2019 está pensado para diseñarse a la medida con sus factores de diseño, no para implantarse entero. Un proveedor que proponga «implementar los 40 objetivos» está vendiendo horas, no gobierno.

Cómo implantarlo en 5 fases

Fase 1 — Levantar lo que ya se decide, y quién lo decide (2-3 semanas)

Antes de diseñar nada, documentar la realidad: las últimas veinte decisiones de tecnología de la empresa, quién las tomó, con qué información y qué pasó. El entregable es una lista de decisiones sin dueño claro. Casi siempre aparecen las suscripciones que nadie recuerda haber autorizado.

Fase 2 — Definir la tabla de facultades y el alcance (1-2 semanas)

Quién aprueba qué, hasta qué monto, con qué revisión previa. Es el documento más corto del proyecto y el que más cambia la conducta. Aquí también se acota el alcance: qué entidades, qué sitios y qué tipo de tecnología cubre el sistema de gobierno.

Fase 3 — Escribir el mínimo de políticas exigibles (4-8 semanas)

Media docena, no treinta: uso aceptable, accesos, respaldo y recuperación, adquisición de servicios en la nube, dispositivos y trabajo remoto, y uso de inteligencia artificial. Cada una con su dueño, sus excepciones y su fecha de revisión. El detalle de cómo se redactan está en cómo definir políticas de tecnología.

Fase 4 — Montar el foro de decisión y su cadencia (1 semana, después todos los trimestres)

No hace falta un «comité de gobierno de TI» con reglamento. Hace falta un punto fijo en una reunión de dirección que ya exista, con tres entradas: el portafolio de iniciativas y su avance, el mapa de riesgos con dueño de negocio, y las excepciones vigentes con su fecha de caducidad. Cuarenta y cinco minutos al trimestre, con acta.

Fase 5 — Medir y corregir (continuo, primera revisión a los 6 meses)

A los seis meses se comprueba lo único que importa: si aparecieron compras fuera de la tabla de facultades, cuántas excepciones caducaron sin renovarse y si el respaldo se restauró de verdad en una prueba. Un gobierno que nunca detecta un incumplimiento no está vigilando.

Rango habitual de punta a punta para una empresa mediana que arranca de cero: de tres a seis meses hasta tener la estructura operando. El factor que más mueve ese plazo no es el tamaño de la empresa, sino si la dirección general asiste a las sesiones o manda a alguien en su lugar.

7 errores que lo convierten en burocracia

1. Escribir políticas que nadie puede cumplir. Una regla que obliga a un trámite de tres días para instalar una aplicación produce dos cosas: incumplimiento generalizado y una política que ya no protege nada. Se escribe lo que se puede sostener.
2. Copiar un marco sin diseñarlo. Adaptar una plantilla genérica con el nombre de la empresa da un documento correcto y ajeno. Se nota en la primera excepción: nadie sabe a quién pedírsela.
3. Dejar los riesgos tecnológicos en TI. Si el dueño del riesgo es quien opera el control, no hay independencia y el riesgo residual nunca se acepta formalmente. Es el error que hace que, cuando algo pasa, nadie hubiera decidido correr ese riesgo.
4. Un comité sin facultades. Reuniones donde se informa pero no se decide. La prueba es simple: si en el acta no hay ninguna decisión con dueño y fecha, no era un foro de gobierno.
5. Confundir vigilancia con desconfianza. El gobierno no existe para controlar a las personas: existe para que las decisiones de mucho dinero o mucho riesgo no las tome una sola persona sin contraste. Cuando se comunica como control, se sabotea.
6. No cerrar el ciclo de excepciones. Se autorizan excepciones, se registran y nadie las vuelve a mirar. A los dos años, la mitad de las políticas están derogadas de hecho y nadie lo sabe.
7. Arrancar por la herramienta. Comprar una plataforma de riesgos antes de decidir quién es dueño de qué riesgo produce un catálogo vacío que se llena una vez y se abandona.

Ejemplo: el gobierno mínimo de una empresa de 120 personas

Para aterrizarlo, así se ve el sistema de gobierno de TI de una empresa de servicios de alrededor de 120 personas, con un responsable de sistemas, dos técnicos y todo lo demás contratado en la nube. Es un ejemplo ilustrativo, construido para mostrar el tamaño correcto de la estructura.

Seis políticas, no treinta. Tres indicadores, no veinte. La diferencia no es falta de rigor: es que se gobierna lo que tiene dinero o riesgo detrás, y lo demás se gestiona. Para dimensionarlo con un punto de comparación verificable: un sistema de gestión de seguridad de la información bajo ISO/IEC 27001:2022 —que es un marco mucho más documental y además auditable por un tercero— nos ha requerido del orden de 34 políticas, 25 procedimientos y 46 formatos para cubrir la totalidad de sus controles. Si alguien propone ese volumen para el gobierno de TI de una empresa de 120 personas, la pregunta correcta es por qué.

Preguntas frecuentes

Conclusión: tres decisiones

El gobierno de TI sirve cuando resuelve un problema que la empresa ya tiene: compras que nadie autorizó, riesgos sin dueño, decisiones de mucho dinero tomadas por una sola persona sin contraste. Cuando se monta por el organigrama, se convierte en el comité que todos evitan.

Si vas a arrancar, tres decisiones ordenan el resto: escribe la tabla de facultades con montos antes que cualquier política, asigna cada riesgo tecnológico a un dueño de negocio y no a sistemas, y ponle fecha de caducidad a toda excepción desde la primera. Las tres se toman en la primera semana y determinan si el sistema sigue vivo en dos años.