Gobernanza de datos e IA suena a algo que se resuelve con una política de diez páginas que nadie lee. En la práctica, es lo contrario: es la diferencia entre que un agente de IA tenga acceso solo a lo que necesita, o que termine leyendo el sueldo de todo el directorio porque nadie revisó los permisos antes de conectarlo. Si tu empresa ya tiene algún equipo usando IA generativa —y a estas alturas de 2026, casi todas la tienen, aunque sea de forma informal— este es el momento de ponerle estructura antes de que un incidente te obligue a hacerlo de apuro.
Por qué esto ya no puede esperar
Hace tres años, gobernanza de datos era un tema exclusivo del área de TI o de cumplimiento. Hoy cualquier colaborador con acceso a Copilot, ChatGPT Enterprise o un agente interno puede, sin mala intención, exponer información que no debería salir de un sistema cerrado. El problema no es la herramienta, es que la mayoría de empresas conectó la IA a sus datos antes de decidir quién puede preguntar qué.
He visto el patrón repetirse en distintos tamaños de empresa: alguien de un área de negocio pide acceso a un agente conversacional sobre una base de datos "para ir más rápido", el área técnica lo habilita con los permisos que tenía a la mano, y seis meses después nadie recuerda exactamente qué puede ver ese agente ni por qué. Eso no es un problema hipotético de seguridad, es el estado real de bastantes organizaciones ahora mismo.
Las tres preguntas que ordenan el tema
No hace falta un comité de gobierno de datos de treinta personas para empezar. Con responder bien estas tres preguntas, la mayoría de empresas ya está adelante del promedio:
- ▸¿Quién puede ver qué? Mapea qué datos sensibles (financieros, de clientes, de RR.HH.) están conectados a algún sistema de IA, y si el acceso respeta los mismos permisos que ya tenías definidos para personas.
- ▸¿Qué modelo procesa la información y dónde queda? No es lo mismo un modelo que procesa datos en tu propia nube con un contrato empresarial, que una cuenta personal de alguien del equipo usando la versión gratuita de un chatbot.
- ▸¿Quién responde si algo sale mal? Define a una persona o equipo responsable de revisar incidentes de IA, igual que ya existe para incidentes de seguridad de la información.
Lo que convierte esto en gobernanza real y no en un documento de buenas intenciones es que estas tres preguntas se revisen cada vez que se conecta un nuevo caso de uso, no una sola vez al año.
La objeción más común que escucho es "esto nos va a hacer más lentos". Es al revés: sin reglas claras, cada área negocia sus propios permisos por su cuenta, y eso tarda más que tener un criterio único desde el principio.
Un caso típico (y por qué se repite tanto)
Una empresa mediana de servicios financieros conecta un asistente interno a su base de reportes para que los analistas puedan preguntar en lenguaje natural en vez de armar consultas SQL. El proyecto arranca con tres personas y buenas intenciones. En menos de dos meses, otras cuatro áreas piden acceso al mismo asistente, cada una con una necesidad distinta, y nadie se detuvo a revisar si las nuevas áreas debían ver los mismos datos que las primeras tres.
Nueve meses después, alguien de un área sin relación con finanzas descubre, por accidente, que puede preguntarle al asistente por cifras de otra gerencia que no le correspondían. No hubo mala intención de nadie: el agente simplemente heredó permisos amplios porque en el momento de conectarlo nadie pensó que escalaría tan rápido. Esto pasa en empresas con equipos técnicos muy capaces, el problema nunca fue la falta de talento, fue la falta de un criterio escrito antes de que el proyecto creciera.
El rol del Data Architect en todo esto
La gobernanza técnica —permisos, catálogo de datos, linaje, control de acceso por rol— no la resuelve una política escrita, la resuelve una arquitectura de datos bien diseñada. Si tu empresa no tiene a alguien dedicado a eso, cada equipo de IA va a improvisar su propia versión de "seguro", y esas versiones casi nunca son compatibles entre sí cuando después necesitas auditarlas todas juntas.
Esto no significa que necesites contratar a alguien nuevo de inmediato. En varios de los procesos que acompañamos, la solución fue formar a una persona que ya conocía los sistemas internos en estas prácticas, porque entender el contexto del negocio pesa tanto como la técnica.
Cómo lo venimos trabajando con otras empresas
En DataPath hemos formado a más de 1,500 profesionales y trabajado con más de 100 empresas en la región, entre ellas Entel, BCP y Scotiabank. Un patrón que se repite: el equipo técnico sabe de IA pero nunca formalizó gobernanza de datos, y el equipo de cumplimiento conoce la gobernanza pero no entiende cómo cambia con IA generativa de por medio. El programa que mejor funciona junta a ambos perfiles en el mismo proceso.
Nuestros instructores siguen trabajando hoy en el puesto que enseñan, así que no es teoría de hace cinco años: traen los mismos problemas que tu equipo va a enfrentar la próxima semana. Y como no todos en un equipo parten del mismo nivel, corremos tres niveles en paralelo dentro del mismo grupo —Iniciación, Aplicada y Avanzada— con una evaluación previa que decide dónde entra cada persona, en vez de forzar a todos al mismo ritmo.
Cómo empezamos
El proceso con una empresa nueva tiene cuatro pasos, sin letra chica: conversamos para entender tu situación actual, hacemos un diagnóstico sin costo de dónde está parada tu organización en gobernanza de datos e IA, diseñamos un plan a la medida (no un curso genérico), y lo dictamos midiendo resultados concretos, no solo asistencia.
Si tu empresa ya tiene IA conectada a datos sensibles y nadie ha revisado formalmente los permisos, probablemente es momento de esa conversación. Puedes agendarla desde /empresas.
Si el foco específico de tu empresa es cumplimiento y política de uso de IA, el programa AI Governance está diseñado para el área legal y de cumplimiento en concreto.
Y si lo que necesitas es formar a tu equipo técnico en arquitectura de datos de fondo —el catálogo, los permisos, el linaje, todo lo que sostiene la gobernanza en la práctica— la ruta Data Architect es la que recomendamos revisar primero.
La inversión siempre se conversa después del diagnóstico, según el tamaño del equipo y el alcance del plan: no publicamos precios de catálogo porque cada empresa parte de un punto distinto, y cobrarte por algo genérico no te sirve de nada.
Lo que no te conviene postergar
El costo de no hacer esto no se ve hasta que aparece: un cliente pregunta qué pasa con sus datos cuando usas IA, un auditor pide evidencia de control de acceso, o —el caso que más me ha tocado ver— un agente conectado de forma apurada responde algo que no debía, frente a la persona equivocada. Ordenar esto antes cuesta una fracción de lo que cuesta resolverlo después de que ya pasó.
Tampoco se trata de frenar la adopción de IA hasta tener un marco perfecto, eso tampoco funciona: las áreas de negocio van a seguir buscando formas de ir más rápido con o sin permiso formal, y bloquear todo solo empuja a la gente a usar herramientas personales fuera del control de la empresa, que es exactamente el escenario que querías evitar. El objetivo realista es tener el criterio mínimo —las tres preguntas de arriba— antes de que el siguiente caso de uso se conecte, no después de que ya esté en producción con cien usuarios.
