La gobernanza de la IA no es un departamento. Es una arquitectura.

La política de cuarenta páginas que nadie lee

Imagine un escenario típico. La responsable de cumplimiento de una empresa de servicios sanitarios en Madrid, con 80 empleados, envía al director general la versión final de la Política de Uso Aceptable de IA. Cuarenta y una páginas. Diecisiete secciones. Referencias cruzadas al RGPD, la Ley de IA de la UE, ISO 42001 y el sistema de gestión de seguridad de la información existente.

Le llevó seis semanas redactarla.

Es, según cualquier criterio profesional, un documento competente. Y no vale nada.

Tres meses después, durante una auditoría rutinaria del DPO, el auditor formula una pregunta sencilla: «Muéstreme qué empleados usaron qué herramientas de IA en febrero. Muéstreme que su política fue seguida.»

Nadie puede responder. No hay registros. No hay un sistema central. La política indicaba que los empleados «deben usar únicamente herramientas de IA aprobadas para fines empresariales» — pero no existe ningún mecanismo técnico que lo haga cumplir, ninguna lista de herramientas aprobadas que alguien mantenga realmente, y ningún registro de quién usó qué.

La política existe. La gobernanza, no.

Este patrón es el estado por defecto de la gobernanza de la IA en las PYME europeas en 2026. Y es la razón por la que la mayoría de las políticas de IA fracasan al primer contacto con una auditoría. Escribimos sobre el problema más amplio — empleados que usan herramientas de IA fuera de cualquier marco — en nuestro artículo sobre la IA en la sombra y la multa invisible del RGPD. Este artículo retoma donde aquel terminó: qué hacer concretamente al respecto.

Por qué esto le ocurre a todas las empresas que lo intentan

La empresa sanitaria hace lo que hace toda PYME bien intencionada cuando la «gobernanza de IA» llega a la agenda. Se lo asignan a una persona. Esa persona redacta un documento. El documento se distribuye. Todo el mundo se siente mejor.

Y nada cambia realmente en la forma en que funciona la empresa.

La razón es estructural, no humana. Un documento de política no tiene dientes. Describe un comportamiento sin producirlo. En una empresa de 30, 80 o 200 personas, no hay nadie cuyo trabajo sea recorrer las instalaciones comprobando que se cumple la política. No existe una capa de aplicación entre la palabra escrita y lo que realmente ocurre en las pantallas de los empleados.

Así que los empleados hacen lo más rápido. Pegan un contrato en ChatGPT Plus porque su suscripción personal ya está abierta. Suben un CV a Gemini porque produce mejores resúmenes. Usan Perplexity para investigación de casos porque un compañero lo recomendó. Cada una de estas decisiones es individualmente razonable. Colectivamente, son exactamente el patrón que la política debía prevenir.

Espere. Léalo de nuevo.

La política no falló porque estuviera mal redactada. Falló porque una política es la herramienta equivocada para este trabajo.

Los reguladores ya han señalado esto

No es una preocupación teórica. La Autoriteit Persoonsgegevens holandesa, la CNIL francesa y el BfDI alemán han publicado cada uno en 2024–2025 orientaciones que señalan el uso no gestionado de herramientas de IA por los empleados como un patrón que justifica medidas coercitivas. El razonamiento jurídico se basa en los Artículos 5, 24 y 32 del RGPD — minimización de datos, responsabilidad del responsable del tratamiento y seguridad del tratamiento. Por encima, la Ley de IA de la UE añade obligaciones de transparencia y responsabilidad que escalan con la categoría de riesgo del uso de la IA.

El hilo conductor de todas estas orientaciones: la intención es irrelevante. Ya sea que un empleado haya pegado un contrato de cliente en una herramienta de IA de consumo intencionalmente, por accidente o porque el departamento de TI nunca le dijo que no lo hiciera — el empleador asume la responsabilidad. El documento de política que prueba «les dijimos que no lo hicieran» no es una defensa. La evidencia de controles activos sí lo es.

La gobernanza no es lo que usted escribe. Es lo que ocurre por defecto.

Las grandes empresas pueden permitirse pensar lo contrario. Tienen equipos de cumplimiento, departamentos de auditoría, responsables de seguridad informática y, a veces, un Chief AI Officer. Cada uno de esos roles existe para traducir la intención escrita en realidad operativa. Una política en un banco de 10.000 personas es solo la cima de una alta pila de mecanismos que hacen real la política.

En un despacho de asesoría fiscal de 30 personas, no hay esa pila. Hay el documento de política, y hay lo que los empleados hacen el lunes por la mañana. La brecha entre ambos no está gestionada.

La alternativa que funciona es arquitectónica. En lugar de escribir reglas y esperar que la gente las siga, usted cambia la forma de la infraestructura para que las reglas se apliquen por defecto. Nadie tiene que recordarlo. Nadie tiene que comprobarlo. La única forma de usar la IA en el trabajo es la forma conforme, porque así es como funciona el sistema.

Esta no es una idea nueva en materia de seguridad. Es cómo las empresas modernas gestionan las contraseñas (SSO), el acceso a la red (VPN ligado a identidad) y el intercambio de archivos (SaaS gestionado con DLP). Usted no escribe una política que diga «los empleados deben usar contraseñas seguras». Implementa un gestor de contraseñas que hace imposibles las contraseñas débiles. Gobernanza por arquitectura.

La gobernanza de la IA en 2026 se encuentra en el mismo punto de inflexión en que estaban las contraseñas en 2012. La mayoría de las PYME todavía la tratan como un problema de política. Las que van por delante ya la tratan como un problema de arquitectura.

El modelo Architecture-First Governance de Custos

Aplicado específicamente a la IA, el enfoque arquitectónico se resuelve en tres capas. Lo llamamos el modelo Architecture-First Governance. Es el compromiso estructural mínimo que una empresa necesita para tener una gobernanza de IA defendible sin un programa de gobernanza dedicado.

Capa 1 — Propiedad. Cada acción de IA está vinculada a un usuario identificado. No una cuenta de equipo. No una clave compartida. Una persona, una identidad, un registro de auditoría. Esto parece trivial. Es el punto de fallo único más común en el uso de IA en las PYME, porque la mayoría de los equipos comparten una cuenta de ChatGPT o un plan de Gemini Workspace. Si no puede atribuir una acción a una persona, no puede gobernarla.

Capa 2 — Aplicación. Las reglas que existen solo como texto no son reglas. Las reglas aplicadas por la plataforma sí lo son. La aplicación significa: solo los proveedores LLM preaprobados son utilizables; los límites presupuestarios por usuario se bloquean antes de la llamada a la API, no después; el acceso a los proveedores es gestionado por administradores, no por usuarios. El empleado no tiene la opción de sortear la política porque las opciones para hacerlo no están disponibles en el producto.

Capa 3 — Evidencia. La gobernanza sin evidencia es una afirmación. La gobernanza con evidencia es una defensa. Cada solicitud, cada proveedor, cada usuario, cada marca de tiempo — registrados en un registro de auditoría inmutable, conservados durante al menos 12 meses, exportables con un clic para un regulador, auditor, asegurador o cliente que lo solicite. La evidencia es la gobernanza. Si no puede producirse, la gobernanza no tuvo lugar.

Estas tres capas no requieren un documento de política. Requieren una decisión de infraestructura. Una vez tomada, la política se escribe sola — en un párrafo, no en cuarenta páginas, porque la arquitectura es la política.

Cómo se ve esto en la práctica

Volvamos a la empresa sanitaria. Tras el hallazgo de la auditoría, no redactan una política mejor. Cambian la arquitectura.

Cada empleado que necesita acceso a la IA es invitado a un único espacio de trabajo. El espacio de trabajo tiene cuatro proveedores LLM habilitados (OpenAI, Anthropic, Google, Mistral) porque son los proveedores con cero retención de datos en el nivel de API — una base que cubrimos en detalle en nuestro artículo sobre por qué la cero retención de datos es el ajuste por defecto que nadie marcó. Cada usuario tiene un límite presupuestario mensual — normalmente entre 30 € y 80 € según el rol — aplicado antes de que la llamada a la API llegue al proveedor, no después. El administrador tiene una vista de solo lectura de cada solicitud de todo el equipo.

La nueva política de IA tiene una página. Dice: «El uso de IA para fines empresariales se realiza a través del espacio de trabajo de Custos. Las cuentas personales de IA no están permitidas para datos de clientes. Cualquier pregunta al respecto, consulte al DPO.»

Eso es todo. El resto es arquitectura.

Cuando llega la próxima auditoría del DPO, cae la misma pregunta: muéstreme quién usó qué herramienta de IA en febrero. Esta vez el administrador exporta el registro. Tres clics. Hecho.

La implicación incómoda

Si la gobernanza architecture-first funciona, la mayor parte del sector de gobernanza está resolviendo el problema equivocado. La plantilla de política de cuarenta páginas, el marco de madurez de gobernanza de IA, el proyecto de implementación de ISO 42001 — estos son productos que asumen que la gobernanza es algo que se hace. Son útiles para organizaciones lo suficientemente grandes como para tener una función de gobernanza.

Para el otro 99 % de las empresas europeas, la gobernanza es algo que hace su infraestructura. Y eso cambia lo que usted compra.

No compra una plantilla de política. No contrata a un consultor de gobernanza. Elige una plataforma de IA donde la gobernanza ya está integrada. La plataforma es la gobernanza. La política es un párrafo que reconoce la plataforma.

Por eso Custos AI incluye control de acceso basado en roles, registro de auditoría, listas de autorización de proveedores y límites presupuestarios estrictos por usuario como características estándar en cada plan — no como complementos enterprise. Estas no son características. Son la arquitectura de la gobernanza. Si no están en el producto, no hay gobernanza, independientemente de lo que diga la presentación de ventas.

Pero hay un inconveniente

La gobernanza architecture-first responde al qué y al cómo. No responde a la pregunta más difícil: ¿quién es responsable cuando la arquitectura falla?

Una plataforma puede aplicar reglas, registrar cada acción y producir evidencia a demanda. No puede asignar responsabilidad. Cuando un directivo pega una hoja de cálculo de salarios en el espacio de trabajo aprobado para pedir un resumen — en contra de la política explícita — y eso se convierte en una brecha, la arquitectura registra lo que ocurrió: quién, cuándo, qué archivo, qué proveedor. Pero la cuestión de la responsabilidad sigue recayendo en una persona. Y la mayoría de las PYME no han pensado en quién es esa persona.

Ese es el problema más profundo de la IA en la sombra — el que no desaparece cuando centraliza sus herramientas. Lo cubrimos en detalle aquí:

IA en la sombra: La multa invisible del RGPD para pequeñas empresas