¿Qué es la gobernanza de IA?

La gobernanza de IA es el modelo operativo que decide qué sistemas de IA permite una empresa, qué datos y tools pueden usar, quién responde por ellos y qué evidencia se conserva cuando actúan. Incluye modelos, clientes de IA, agentes, prompts, servidores MCP, skills, plugins, credenciales y outputs.

El plano técnico suele combinar un catálogo de capacidades aprobadas, políticas de identidad y acceso, LLM routing, gateways de MCP, controles de seguridad en runtime, límites de uso, traces, evaluaciones y respuesta a incidentes. Estos controles convierten la política en decisiones que permiten, niegan, modifican, pausan o mandan una acción a revisión.

La gobernanza de IA no es un comité que revisa un documento una vez por año. Es un ciclo continuo: descubrir uso real, aprobar patrones útiles, aplicar controles en runtime, observar outcomes, investigar excepciones y actualizar el camino aprobado a medida que los equipos adoptan nuevos modelos y tools.

La adopción de IA rara vez espera a un programa central. Las personas instalan clientes de IA, conectan cuentas OAuth personales, agregan servidores MCP, copian datos internos en prompts y comparten skills o plugins locales. Este shadow AI puede ser productivo, pero la empresa puede no saber qué sistemas guardan datos de clientes, código, contratos, contraseñas o API keys.

Los agentes aumentan el impacto porque pueden actuar, no solo generar texto. Una tool de email con permisos excesivos puede enviar datos afuera. Una descripción de tool envenenada puede cambiar el comportamiento. Una instrucción inyectada en un ticket o documento puede hacer que un agente legítimo llame al sistema equivocado.

Una buena gobernanza no empieza con una prohibición total. Crea un camino aprobado más fácil que la configuración informal: modelos, conectores y tools autorizados con owners claros y acceso rápido. Seguridad concentra el blocking en servidores desconocidos, privilegios excesivos, datos sensibles, acciones destructivas y comportamiento que se aleja de la tarea original.

La primera capa es inventario. Configuración de dispositivos, logs de aplicaciones, grants OAuth, repositorios y actividad de red pueden mostrar qué clientes, modelos, servidores MCP, skills, plugins y agentes están en uso. Cada capacidad aprobada necesita owner, propósito, dependencias, clasificación de datos, estado de acceso y evidencia de adopción o falla.

La segunda capa es control en runtime. Un LLM router selecciona modelos y regiones aprobados, aplica presupuestos y rechaza workloads restringidos. Las políticas de identidad limitan acceso por persona, grupo, service account, agente, cliente, conector, tool y recurso. Un gateway de MCP evalúa tool calls, mientras los controles de seguridad inspeccionan prompts, contenido recuperado, argumentos, intención y outputs.

La tercera capa es observabilidad y respuesta. Un solo trace conecta actor, modelo, prompt, tool calls, políticas, aprobaciones, costo, latencia, hallazgos y resultado final. La respuesta puede ser aprobar un patrón de shadow AI, migrarlo a infraestructura gestionada, eliminar configuración obsoleta, reducir permisos, rotar una credencial, bloquear la actividad o escalar un incidente.

Una persona de desarrollo usa un asistente de código aprobado para diagnosticar una falla en un webhook de producción. La tarea contiene logs y un archivo de configuración. El LLM router mantiene la solicitud en un modelo aprobado, el detector reemplaza una API key antes de la inferencia y la política permite lectura de logs, pero no gestión de credenciales.

El repositorio también contiene un README que le pide al asistente subir la configuración a una tool externa. Seguridad clasifica esa instrucción como contenido recuperado no confiable. El gateway de MCP niega la llamada porque el conector no está aprobado y los argumentos contienen un patrón de secreto. La persona recibe un siguiente paso seguro en lugar de un rechazo genérico.

El trace muestra persona, cliente, modelo, repositorio, tools solicitadas, evento de redacción, destino bloqueado, versión de política, latencia y acción final. Seguridad rota la key expuesta, plataforma corrige el workflow aprobado y el owner registra el patrón de shadow AI para que otros equipos no lo repliquen.

Asigná responsables antes de elegir controles. Seguridad define amenazas y respuesta a incidentes. Plataforma opera catálogo, gateway, router y confiabilidad. Los owners de datos definen usos permitidos. Los owners de negocio aceptan riesgo. Cada agente de alto impacto necesita una persona responsable y una condición de parada.

Creá niveles de riesgo según datos y acción, no según la marca del modelo. Leer documentación pública no es igual que enviar email, cambiar producción, emitir un reembolso o acceder a registros regulados. Vinculá cada aprobación con la acción y parámetros exactos, hacela expirar y evitá que una aprobación anterior autorice una solicitud modificada.

Medí cobertura y outcomes: clientes descubiertos versus gestionados, servidores MCP aprobados versus shadow, owners activos, llamadas de alto riesgo bloqueadas, secretos detectados, approval rate, fallas de tools, costo por equipo, tiempo de remediación e intentos repetidos de bypass. Redactá datos sensibles de los traces y mantené rollback, rotación de credenciales y kill switches.