Gobernanza es una palabra que llega tarde a la mayoría de los proyectos de IA. Suele aparecer cuando el sistema ya funciona y alguien de jurídico pregunta qué pasa con los datos personales de los clientes que están dentro de esas conversaciones.
En términos operativos, gobernanza es control interno: quién aprueba, quién responde y qué queda registrado. Puesta al final es un anexo legal. Puesta al principio es una decisión de arquitectura, y cuesta bastante menos.
Las seis capas
Un sistema de IA en una empresa se gobierna por capas, de abajo hacia arriba:
- Datos. Qué información entra al sistema, de dónde viene, cuánto tiempo se conserva y qué se hace con la que contiene datos personales.
- Permisos. Acceso de mínimo privilegio: el sistema consulta con los permisos de quien pregunta, no con los del ingeniero que lo construyó.
- Modelos. Qué proveedor, en qué nube, bajo qué condiciones contractuales y con qué alternativa si esas condiciones cambian.
- Evaluación. Exactitud, calidad de recuperación, respuestas inventadas, tiempo de respuesta y costo, medidos de forma continua y no una sola vez.
- Revisión humana. Dónde se detiene el flujo para que una persona apruebe, con criterios explícitos y ruta de escalación.
- Flujo de negocio. Cómo encaja todo lo anterior en el proceso que ya existe, incluida la parte que no es software.
El orden importa. Los permisos mal resueltos en la capa dos no se arreglan con una política en la capa seis, y una revisión humana colocada donde no hay riesgo solo agrega latencia sin agregar control.
Dónde entra la LFPDPPP
La Ley Federal de Protección de Datos Personales en Posesión de los Particulares aplica a los datos personales de clientes y empleados que ese sistema toca. En un proyecto de IA eso llega por caminos que no siempre se anticipan: el histórico de tickets trae nombres y correos, los contratos traen datos de representantes, los expedientes de recursos humanos traen prácticamente todo.
Las obligaciones que se vuelven decisiones técnicas son tres. El aviso de privacidad y el consentimiento tienen que cubrir la finalidad real del tratamiento, incluida la de alimentar un sistema automatizado. El control de acceso tiene que ser demostrable, no declarado. Y los derechos ARCO —acceso, rectificación, cancelación y oposición— tienen que poder ejercerse sobre datos que ahora viven también en un índice de búsqueda o en una bitácora de conversaciones.
Esa última es la que se olvida. Si un titular pide la cancelación de sus datos y el sistema los conserva en un índice vectorial que nadie sabe purgar, el cumplimiento se rompe en el lugar donde nadie estaba mirando.
Decisiones de arquitectura que la gobernanza determina
- Dónde se procesan los datos sensibles: en un modelo comercial, en una instancia dedicada dentro de tu nube o en un despliegue local. La respuesta cambia con la categoría del dato, no con la preferencia técnica del equipo.
- Qué se registra en bitácora y por cuánto tiempo. La trazabilidad es lo que permite auditar una decisión seis meses después; también es un almacén de datos personales que hay que gobernar.
- Qué acciones puede ejecutar un agente por sí mismo y cuáles requieren aprobación, con límites de monto o de alcance escritos en el sistema y no en un manual.
- Cómo se revoca el acceso cuando alguien cambia de rol, incluido el acceso indirecto que da consultar un índice construido sobre documentos restringidos.
Por qué esto se decide al principio
Reconstruir permisos sobre un sistema que ya opera implica volver a indexar, volver a probar y volver a convencer a las áreas que ya habían aprobado. Diseñarlos desde el inicio cuesta días. La diferencia es de un orden de magnitud, y es la razón por la que tratamos la gobernanza como parte de la primera entrega y no como una fase posterior.
El beneficio compuesto aparece en el segundo caso de uso: hereda los permisos, la trazabilidad y la revisión humana ya probados en el primero, y llega a producción sin repetir la negociación.
Nuestro propio tratamiento de datos está descrito en el aviso de privacidad del sitio.