La gobernanza de IA empieza por saber qué sistemas existen, para qué se usan, quién responde por ellos y qué datos o acciones pueden tocar. Diseñamos esa capa operativa: inventario, owners, proveedores, permisos, riesgo, supervisión, evidencias y ciclo de cambio. La preparación para el AI Act se trabaja junto al equipo legal, DPO o compliance cuando una decisión requiere interpretación normativa.
Una política genérica no gobierna un sistema. La gobernanza útil conecta cada uso de IA con una finalidad, un owner, un proveedor, unas fuentes, unas acciones permitidas, una forma de supervisión y evidencias que puedan revisarse cuando cambia el modelo o el proceso.
El inventario registra cada sistema o uso de IA que importa para la organización: finalidad, área responsable, usuarios, proveedor o modelo, datos de entrada, integraciones, acciones, nivel de autonomía y estado del sistema. También conviene distinguir si la empresa está actuando como usuaria o deployer de una solución de terceros, si está proporcionando un sistema a terceros o si está desarrollando componentes propios.
Esta distinción cambia las preguntas que hay que responder. No se gobierna igual una herramienta generativa usada por marketing para borradores que un sistema integrado en un producto, una decisión sobre personas o un agente con permiso para escribir en un ERP.
Shadow AI, cuentas personales y funciones de IA que aparecen dentro de SaaS existentes hacen que una política escrita pueda quedarse obsoleta rápidamente. Por eso el inventario necesita un mecanismo operativo de alta, revisión y retirada. El objetivo no es bloquear por defecto, sino saber qué está autorizado, qué información puede utilizarse y quién aprueba una excepción.
Cuando una herramienta cambia condiciones, proveedor, modelo, ubicación del dato o capacidades de acción, el cambio debe poder disparar una revisión. La gobernanza útil acompaña el ciclo de vida; no se termina el día en que se publica una política.
Aplicamos un triage operativo antes de diseñar controles: a quién afecta el resultado, qué datos utiliza, si la salida informa o decide, si el sistema ejecuta acciones, qué posibilidad existe de corregir un error y qué impacto tendría que el resultado fuese incorrecto. Con esa información se puede decidir cuándo basta una guía de uso, cuándo hace falta aprobación humana y cuándo el caso debe escalar a legal, DPO, seguridad o un análisis regulatorio más específico.
No presentamos este triage como una clasificación jurídica definitiva bajo el AI Act. Esa clasificación debe validarse con los perfiles responsables cuando corresponda.
A septiembre de 2026 ya hay obligaciones del AI Act plenamente aplicables. El artículo 4 obliga a proveedores y responsables del despliegue a adoptar medidas de alfabetización en IA; la Comisión aclara que, tras la reforma de 2026, no se exige un nivel individual específico. Sus reglas de supervisión y ejecución se aplican desde el 3 de agosto de 2026. Las obligaciones de transparencia del artículo 50 se aplican desde el 2 de agosto de 2026.
Para los sistemas de alto riesgo, el calendario vigente distingue dos hitos: los casos del Anexo III —por ejemplo determinados usos en empleo, educación, biometría o infraestructuras críticas— pasan a aplicar desde el 2 de diciembre de 2027; los sistemas de alto riesgo integrados en productos regulados del Anexo I, desde el 2 de agosto de 2028.
La gobernanza operativa traduce ese marco a tareas concretas: qué sistemas necesitan informar de forma transparente, qué personas requieren medidas de alfabetización por su rol, qué usos deben escalarse por posible alto riesgo y qué evidencias técnicas conviene conservar. No sustituimos la interpretación jurídica: coordinamos con legal, DPO o compliance y documentamos la parte técnica y operativa.
Fuentes oficiales: Q&A de alfabetización en IA, directrices de transparencia del artículo 50 y orientaciones sobre sistemas de alto riesgo.
La política tiene que reflejarse en arquitectura. Un sistema de consulta puede necesitar filtrado de fuentes por rol; un agente puede necesitar herramientas con permisos mínimos; una automatización puede requerir aprobación antes de escribir; un asistente puede necesitar una respuesta de “no encontrado” en lugar de completar información incierta. Definimos estas fronteras de forma técnica y comprobable.
También decidimos qué logs hacen falta para investigar un incidente o una salida incorrecta sin almacenar información de más. La trazabilidad debe ayudar a reconstruir qué versión, fuente, acción y aprobación intervinieron cuando sea relevante.
Una empresa puede depender de proveedores de modelos, plataformas de automatización, bases vectoriales, servicios cloud y aplicaciones SaaS que incorporan IA. Para cada dependencia registramos qué función cumple, qué datos recibe, qué garantías necesitamos, cómo se controla el acceso y qué plan existe si cambia precio, comportamiento, disponibilidad o condiciones.
No siempre tiene sentido perseguir independencia total. Sí tiene sentido saber qué dependencias son críticas, qué parte del sistema podemos sustituir y dónde existe lock-in operativo.
Cada control necesita un responsable y una evidencia razonable: registro del sistema, revisión de proveedor, dataset o fuentes autorizadas, casos de evaluación, decisiones de aprobación, incidentes, formación por rol o historial de cambios. El nivel de evidencia debe ser proporcional al uso; documentarlo todo con la misma intensidad sólo crea burocracia.
Una matriz RACI sencilla suele ser más útil que un comité abstracto: quién propone, quién aprueba, quién opera, quién revisa riesgo y quién decide detener o cambiar el sistema.
Un modelo nuevo puede cambiar calidad, coste o comportamiento aunque la interfaz parezca idéntica. Una nueva fuente puede alterar permisos; una tool adicional puede aumentar autonomía. Diseñamos gates para cambios relevantes: qué debe reevaluarse, quién aprueba y cuándo hay que volver a una versión anterior.
También definimos retirada: desactivar accesos, revocar credenciales, conservar las evidencias necesarias y asegurar que un workflow no queda dependiendo de un componente que ya no existe. El final de vida forma parte de la gobernanza.
Una implementación fiable mezcla piezas distintas: software determinista para reglas previsibles, modelos cuando el lenguaje o la ambigüedad importan, recuperación de conocimiento cuando la respuesta debe apoyarse en fuentes y supervisión humana cuando el coste del error exige criterio. El objetivo no es maximizar la cantidad de IA, sino diseñar el sistema que mejor resuelve el trabajo.
No aplicamos una plantilla idéntica a todos los sectores. Seleccionamos aquí contextos donde datos, trazabilidad, supervisión o efectos sobre personas hacen especialmente importante diseñar ownership y controles claros.
Cuando la IA interviene en contenidos, evaluación, orientación o servicios a estudiantes conviene distinguir uso asistivo, transparencia y decisiones con impacto sobre personas.
Confidencialidad, propiedad intelectual y responsabilidad profesional hacen necesario definir herramientas autorizadas, datos permitidos y revisión de outputs.
Cuando la empresa incorpora IA en su propio producto puede cambiar su rol en la cadena de valor y necesita gobernar versiones, proveedores, evaluaciones y documentación técnica.
Preguntas sobre ownership, inventario, regulación y controles que conviene responder antes de convertir la gobernanza en una colección de documentos desconectados.
Como mínimo, un inventario de usos relevantes, finalidad, owner, proveedor o modelo, datos, usuarios, integraciones, nivel de autonomía y controles. A partir de ahí se añaden políticas, evaluaciones, evidencias, formación y procesos de cambio de forma proporcional al riesgo.
No. Diseñamos y desplegamos la capa técnica y operativa de gobernanza: inventario, ownership, permisos, evaluaciones, evidencias y procesos. Cuando hace falta interpretar la norma, clasificar jurídicamente un caso o certificar un sistema de gestión, trabajamos con el equipo legal, DPO, compliance o especialistas externos de la organización.
Parte del régimen ya es aplicable. Por ejemplo, las obligaciones de transparencia del artículo 50 se aplican desde el 2 de agosto de 2026. Otras obligaciones, especialmente determinadas reglas para sistemas de alto riesgo, siguen calendarios posteriores. Como el calendario y las guías pueden evolucionar, enlazamos fuentes oficiales y validamos la interpretación concreta con legal/compliance.
Si su uso es relevante para procesos, datos o decisiones de la empresa, conviene saber quién las utiliza, con qué finalidad, bajo qué cuenta y qué información puede introducirse. El inventario no tiene que tener la misma profundidad para un asistente de bajo impacto que para un sistema integrado en operaciones.
Con tools estrechas, mínimo privilegio, límites de acción y coste, aprobaciones para pasos sensibles, trazabilidad y una ruta de escalado. También evaluamos secuencias completas, no sólo la respuesta textual, porque el riesgo está en qué herramientas elige y qué acciones termina ejecutando.
Puede incluirla y normalmente debe coordinarse con ella. La formación se diseña por rol y sistema: no necesita saber lo mismo quien redacta con IA que quien aprueba un agente con acceso a un CRM. Para programas completos enlazamos nuestro servicio de formación y adopción de IA.
No necesariamente. ISO/IEC 42001 puede ser un marco útil para organizaciones que necesiten un sistema de gestión formal o una certificación, pero no toda empresa necesita empezar por ahí. CODE-IA puede preparar la capa operativa y técnica; una certificación formal corresponde a los especialistas y organismos que procedan.
Por un discovery corto del uso real: equipos, herramientas, finalidades, datos y sistemas conectados. Después priorizamos los casos con más impacto o riesgo, asignamos owners y aplicamos controles proporcionados. Si el problema previo es descubrir qué iniciativas merecen inversión, puede encajar primero una auditoría de oportunidades de IA.
La gobernanza no sustituye el delivery técnico. La conectamos con auditoría, formación, integración y desarrollo para que los controles vivan dentro del sistema y del trabajo diario.
Podemos empezar por inventariar usos, owners, proveedores, datos, permisos y acciones. A partir de ahí separamos controles técnicos, decisiones operativas y cuestiones que deben validar legal, DPO o compliance.