Fuentes de datos: CodeRabbit 2025.12 / New Relic 2026 informe, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms anuncio, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. Los casos son escenarios representativos, no se refieren a empresas específicas.

Tu mayor error no es no haber comprado herramientas, es no haber escrito CLAUDE.md

Un CIO de un banco comercial como Santander me dijo: “Hemos comprado herramientas de IA, hemos desplegado modelos y hemos capacitado a las personas, pero en el primer semestre de 2026, el ciclo de entrega prácticamente no ha cambiado”. El responsable del equipo de sistemas principales fue aún más directo: “El código escrito por la IA es utilizable, pero cada vez que lo usamos, tenemos que reescribirlo por completo. No entiende las reglas de nuestro banco, no entiende los requisitos de regulación y no entiende cómo integrarse con ese sistema antiguo de 30 años”.

(Note: He mantenido el título original “CLAUDE.md” ya que es un término específico y no tiene una traducción directa al español. Si se desea, se puede cambiar a un título más descriptivo como “Tu mayor error no es no haber comprado herramientas, es no haber documentado tus procesos”)

El problema no es que la IA no sea lo suficientemente poderosa, sino que no han escrito las reglas. CodeRabbit, en su análisis de 470 solicitudes de extracción de código abierto en diciembre de 2025, presentó una serie de cifras ampliamente citadas: las solicitudes de extracción de código colaborativas con IA contienen en promedio 10,83 problemas, mientras que las solicitudes de extracción de código puramente humanas tienen 6,45 problemas, lo que representa un 70% más de errores que las solicitudes de extracción de código humanas. A medida que avanzamos hacia 2026, la historia no cambia: New Relic descubrió en su informe “2026 State of AI Coding Report” que el 78% de los equipos informaron más incidentes después de implementar código de IA, y el 62% de los líderes técnicos admitieron que sus equipos “confían en no revisar línea por línea antes de lanzar” el código de IA (New Relic, informe oficial 2026, puntuación 0,866, fuente primaria). Ambos conjuntos de datos dicen lo mismo: la IA no carece de capacidad, sino de contexto.

En este punto, agosto de 2026, todas las narrativas sobre “acelerar la transformación de la IA” deben considerarse en un contexto comparativo:

Aprendiendo AI Lentamente

Evolución de la Implementación de Agentes de IA en Empresas Líderes

Empresa	Avances (2026 H1)	Lecciones Aprendidas (2026 H1)
EY	Implementación de Microsoft 365 Copilot para 150,000 empleados, ahorro de 250,000 horas / 2.5 mil millones de dólares; expansión a 400,000 empleados globales	Reconoce que el 95% de aumento de velocidad y el 37% de reducción de costos financieros se deben a la “normalización previa”
Atos	Despliegue en 54 países / 56,000 empleados; ejecución simultánea de 19,000 agentes de IA, control unificado de identidad, seguridad, cumplimiento y gobernanza	Insiste en que “primero se debe implementar la capacidad de gobernanza de Agent 365 y luego escalar”
Microsoft	Índice de Tendencias Laborales 2026: el 82% de los líderes planea ampliar la fuerza laboral con agentes de IA en los próximos 12-18 meses	Reconoce que “el ritmo del cambio organizacional está por detrás del uso individual” — un conflicto clave en el concepto de Frontier Firm

En este artículo, exploraremos cómo empresas líderes como EY, Atos y Microsoft están implementando agentes de IA para mejorar la eficiencia y reducir costos. También examinaremos las lecciones aprendidas y los desafíos que enfrentan en este proceso.

Aprende IA Despacio 001: ¿Por qué la escala multiplica el riesgo?

Fuente: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5; New Relic 2026 State of AI Coding Report.

Dos grupos de comparación nos muestran una realidad: sin regulación, la escalabilidad es multiplicar el riesgo por N. La “rápida” de EY, Atos y Microsoft no se refiere a la velocidad de los modelos, sino a la capacidad de la organización para responder a preguntas sobre cómo utilizar la Inteligencia Artificial. Esto se debe a que la Spec-Driven Development (SDD, Desarrollo Dirigido por Especificaciones) se ha convertido en una práctica común en la primera mitad de 2026, no porque los ingenieros prefieran la documentación, sino porque no escribir regulaciones ya no es posible en un entorno con 19,000 agentes.

Este artículo aborda tres temas: 1) ¿Por qué los defectos de código AI son 1.7 veces más graves que los humanos? 2) ¿Cómo GitHub, AWS, OpenAI, Anthropic y Alibaba han adoptado un enfoque común en la primera mitad de 2026, es decir, usando documentación para controlar el comportamiento de AI? 3) ¿Por qué la Spec-Driven Development es una cuestión de capacidad organizativa y no de elección de herramientas, y cómo se ha implementado en tres fases en la primera mitad de 2026.

Longitud de barra = múltiplo de defectos de IA frente a humano; línea base 1.0× = nivel humano

Línea base 1.0×

Total de problemas

1.7×
IA 10.83 vs humano 6.45 / PR

Errores de lógica / corrección

1.75×

Calidad de código / mantenibilidad

1.64×

Hallazgos de seguridad (combinados)

1.57×

Manejo incorrecto de contraseñas

1.88×

Vulnerabilidades XSS

2.74×
↑ Máximo

Código de IA sin restricciones supera al humano en todas las dimensiones
Finanzas / telecom = conciliación de cumplimiento, gestión de contraseñas, cifrado de campos sensibles, IA no ve nada

Aprende IA Despacio: Desarrollando habilidades en Inteligencia Artificial

1. El error en la tasa de AI no es un problema de modelo, sino de contexto

Un informe de CodeRabbit ha sido citado repetidamente: “La falta de lógica empresarial local en AI: los modelos se basan en la inferencia estadística de código, en lugar de en la comprensión semántica. Sin restricciones estrictas, pueden pasar por alto las reglas sistemáticas internas de los ingenieros experimentados.”

Esta frase explica por qué CodeRabbit, una plataforma de programación AI (una empresa especializada en la revisión de código AI), ha sido la primera en ver estos datos - ellos ven miles de PR cada día, y ven el código escrito por AI todos los días. El descubrimiento más importante no es la cantidad, sino la distribución:

Lógica/Correctitud +75%: errores de lógica empresarial, errores de dependencia, errores de flujo de control, errores de configuración - estos problemas pueden no estar expuestos en las pruebas, pero pueden causar accidentes en el entorno de producción.
Calidad del código +64%: inconsistencias en nombres, estructuras no claras, violaciones de patrones de proyecto - esta es la “categoría de mayor diferencia”. Los ingenieros experimentados pueden ver a simple vista “esto no es nuestra forma de escribir”.
Seguridad +57% (XSS con un máximo de 2,74 veces): manejo de contraseñas inadecuado (1,88 veces), referencias a objetos no seguras (1,91 veces), divulgación de información sensible, deserialización no segura (1,82 veces) - en la industria financiera, esto no es “puedo usarlo”, sino “puedo publicarlo”.

Nota: El informe de CodeRabbit se refiere a la tasa de errores en el código AI, que no es un problema de modelo, sino de contexto. El contexto es la falta de lógica empresarial local en AI, que puede pasar por alto las reglas sistemáticas internas de los ingenieros experimentados.

Aprendiendo AI con Cuidado

Como CIO, es importante recordar que el problema no es que el AI no sea lo suficientemente fuerte, sino que no puede ver.

Volvamos a la realidad de nuestro trabajo. El AI en los sistemas financieros core tiene tres problemas específicos:

Primero, el AI no puede ver 30 años de lógica de contabilidad. Las reglas de control de riesgo de los bancos están escritas en los procedimientos de almacenamiento de los sistemas core - 30 años atrás, nadie recuerda todo. El código lógico generado por el AI parece correcto, pero en el entorno de producción activa la verificación de contabilidad que nadie recuerda, lo que provoca que una gran cantidad de transacciones fallen.

Segundo, el AI no puede ver las restricciones regulatorias. Los contraseñas deben pasar por el sistema de gestión de claves, los campos sensibles deben ser almacenados encriptados, y los registros no pueden imprimir información de clientes - esto es un requisito regulatorio, escrito en los reglamentos internos. El AI no sabe, y el código escrito puede ejecutarse pero no pasa la revisión regulatoria.

Tercero, el AI no puede ver tu deuda técnica. El sistema de hospedaje de 30 años utiliza una interfaz de protocolo propia, y los documentos ya se han perdido. El AI escribe código según el estándar RESTful común, pero después de desplegarlo se descubre que la interfaz no se ajusta - se requieren dos semanas de trabajo de vuelta.

Volvamos a los números de New Relic: el 62% de los equipos “confía ciegamente” en que no revisan el código AI antes de desplegarlo, y el 78% reporta más incidentes después de desplegarlo. Estos dos números juntos dicen que - la tasa de defectos del código AI en sí no es el problema, sino que “no sé qué defectos tiene el código AI” es el problema.

Referencias

Escenario típico: un banco de acciones introduce el desarrollo asistido por AI para el módulo de control de riesgos de su sistema central, y en tres meses, la tasa de devolución de la revisión de cumplimiento aumenta significativamente. El principal problema es la gestión de contraseñas, el cifrado de campos sensibles y la compatibilidad de registros, que son reglas internas que se encuentran en la documentación interna, pero que AI no puede ver. Después de eso, el equipo escribe las reglas principales en CLAUDE.md, y la tasa de devolución disminuye notablemente.

Dos. Las cinco plataformas en 2026 H1: “normas impulsadas” en diferentes caminos

En julio de 2025, GitHub lanzó Spec Kit, y a principios de 2026, AWS Kiro, OpenAI Codex y Anthropic Claude Code completaron la oferta. En mayo de 2026, Alibaba Qoder incluyó “Spec-Driven Workflow” en su posición de producto. Las cinco plataformas en 2026 H1 llegaron al mismo paradigma: utilizar la documentación para restringir el comportamiento de la IA. Esto no es una invención de ninguna empresa, sino una respuesta colectiva de la industria a la “crisis de calidad del código de la IA”.

Analicemos las acciones más recientes de cada plataforma en 2026 H1:

GitHub Spec Kit: Implementación de referencia, control de cinco etapas.

En septiembre de 2025, se lanzó como código abierto y, para el primer semestre de 2026, ya se ha convertido en una implementación de referencia para la industria. 5 comandos básicos + 2 complementarios: /speckit.constitution (principio de no negociación), /speckit.specify (qué hacer y por qué), /speckit.plan (cómo cambiar), /speckit.tasks (dividir tareas), /speckit.implement (ejecutar), más /clarify y /analyze. Su diseño clave es independiente del modelo — un mismo archivo spec/plan/tasks no está vinculado a un agente de ejecución, por lo que Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf y Qwen Code pueden interactuar con él. Esto lo convierte en un “protocolo de SDD a nivel organizacional”, en lugar de un producto exclusivo de GitHub (evaluación de vibecoding.app en junio de 2026, puntuación 0,816, fuente de segundo nivel).

AWS Kiro: Incorporando la automatización de normas en el IDE

En julio de 2025, AWS lanzó Kiro, una herramienta que integra la automatización de normas en el entorno de desarrollo integrado (IDE). En el primer semestre de 2026, Kiro evolucionó hasta convertirse en un IDE de agente completo. El flujo de trabajo de Kiro se divide en tres etapas: requisitos, diseño y tareas.

A diferencia de Spec Kit, Kiro se destaca por su capacidad para “enganchar” archivos de especificación que desencadenan acciones predefinidas de agentes, lo que permite incorporar pasos como la conformidad, la auditoría y la implementación en el flujo de trabajo. Si deseas obligar a tu equipo a escribir especificaciones, elige Kiro, porque sin especificaciones, Kiro no puede iniciarse (AWS Kiro, julio de 2025; documentación de Kiro.dev, 2026).

Nota: En este texto, se ha mantenido el nombre original de la herramienta “Kiro” y se ha traducido el resto del contenido para que sea coherente con el estilo y la estructura del idioma español.

OpenAI Codex: AGENTS.md + Habilidades Combinables

En 2025-2026, AGENTS.md se convirtió en el centro de la atención en el ecosistema. Las habilidades son la clave para la expansión en el primer semestre de 2026: predefinir procesos como “leer tablas de Excel”, “generar SQL” y “ejecutar migraciones de datos” para que se puedan llamar como piezas de Lego. La actividad semanal de Codex en junio de 2026 superó los 5 millones de usuarios, de los cuales el 20% no eran desarrolladores. Esto es un indicio que no debe ser ignorado: la automatización ya no es solo para los equipos de ingeniería, sino para todos, incluyendo productos, operaciones y control de riesgos, que están escribiendo AGENTS.md (Anuncio de OpenAI del 2 de junio de 2026; evaluación de thebcms.com en 2026, puntuación 0,801).

Nota: He mantenido la estructura de Markdown y he traducido el texto de manera natural y fluida, evitando la traducción literal y los términos técnicos han sido preservados. También he utilizado expresiones idiomáticas en español para que el texto sea más comprensible y natural para los lectores hispanohablantes.

Claude Code: CLAUDE.md + .claude/rules/ + Skills

Anthropic denomina el documento de instrucciones del proyecto CLAUDE.md (lanzado en el mercado oficial en febrero de 2026), .claude/rules/ (reglas organizadas por directorios) y Skills (flujos de trabajo compartibles). Claude Code es la herramienta con mayor satisfacción del desarrollador en el primer semestre de 2026 — según una encuesta de JetBrains en 2026.1, con un CSAT del 91% y un NPS del 54, dos encuestas independientes (Pragmatic Engineer en 2026.2) coinciden en esto. Este es el puntaje más alto en la actualidad en la categoría de herramientas de programación de IA (uvik.net en 2026.5, con un puntaje de 0,956, resumen de fuentes de primer nivel). Claude Code alcanzó un ingreso anual de 2.500 millones de dólares en solo 9 meses (según la ronda G de Anthropic en 2026.2), con 112.000 estrellas en GitHub (repositorio de Skills) — los desarrolladores votan con sus pies y demuestran el valor real de la conducción por normas.

Nota: Se han mantenido los términos técnicos y los nombres de herramientas y empresas en su forma original, tal como se especifica en las instrucciones.

Alibaba Qoder: impulsando la normalización en el mercado chino

En agosto de 2025, se lanzó Qoder, que el 15 de mayo de 2026 se actualizó a la versión 1.0, pasando de ser un “IDE de IA” a una “plataforma de desarrollo de agentes autónomos”. Su Spec-Driven Workflow se presentó junto con Quest Mode (tareas autónomas de varios archivos), Expert Mode (trabajo en equipo en paralelo) y RepoWiki (gráficos de conocimiento de repositorios). El 28 de mayo de 2026, se lanzó Cloud Agents (tiempo de ejecución de agentes completamente administrado), y el 21 de julio de 2026, se lanzó Qoder Security (capacidades de seguridad y cumplimiento). Ese mismo mes, se lanzó la versión móvil (Android/iOS/HarmonyOS). Para mayo de 2026, Qoder había superado los 5 millones de usuarios en todo el mundo, y la CLI de Microsoft Teams lo incluyó como uno de los entornos de ejecución de agentes admitidos (Yahoo Finance 2025; Alibaba Cloud 2026; Baidu Baike 2026.7).

Nota: Se han mantenido los nombres de los productos y herramientas originales, como Qoder, y se han traducido los términos técnicos de manera precisa. También se han mantenido las fechas y los números originales.

Aprendiendo a trabajar con IA: un enfoque común

Definir un enfoque común: Escribir explícitamente cómo trabajamos con IA y ponerlo en un documento en el repositorio, para que todos y todas, así como todos los agentes de IA, trabajen con la misma norma. Aunque los detalles de implementación son diferentes (nombre de archivo, número de fases, mecanismos de hook) entre las cinco plataformas, el objetivo es idéntico.

¿Por qué sucedió esto en la primera mitad de 2026? Debido a que el umbral de habilidad de IA ya ha pasado: Claude Code agente autónomo, Codex varios agentes en paralelo, Cursor reestructuración de varios archivos, IA ya no es “herramienta de completar” sino “colaborador”. Puedes darle a un nuevo colaborador un documento de bienvenida, también puedes darle a IA.

Tres: La norma es la capacidad de la organización, no la elección de herramientas

Esta es la regla más importante para los tomadores de decisiones. La norma no es elegir herramientas, sino definir “cómo nuestra organización trabaja con IA”. No importa si elegimos el Kit de especificaciones de GitHub o Claude Code, lo importante es que hayamos escrito la norma en un documento, lo hayamos puesto en el repositorio y lo hayamos hecho trabajar para todos y todas, así como para IA.

Sin esto, incluso las mejores herramientas solo harán que el equipo trabaje a un ritmo más rápido para crear más deudas.

Aprendiendo AI Lentamente 001: La importancia de la gobernanza de la IA en la implementación a gran escala

En el primer semestre de 2026, la implementación a gran escala de tecnologías de IA se ha convertido en un tema cada vez más relevante. Microsoft, en su retrospectiva de FY26 de julio de 2026, presentó dos casos de estudio, EY y Atos, utilizando el modelo de “Frontier Firm” - no debido a la novedad del modelo, sino porque ambas empresas habían respondido previamente a la pregunta de “¿Cómo utilizar la IA?”:

EY: Establecer un marco de gobernanza antes de implementar a gran escala. EY implementó Microsoft 365 Copilot en 150.000 personas entre 2024 y 2025, lo que les permitió ahorrar 25 millones de horas y aproximadamente 250 millones de dólares. Sin embargo, esto solo fue posible después de que EY creara un marco de gobernanza unificado utilizando Power Platform, Copilot Studio, Azure, Foundry y Fabric. Esto les permitió integrar las normas, la conformidad y la auditoría en un solo entorno. Como resultado, lograron un aumento del 95% en la velocidad, una disminución del 37% en los costos de operación financiera y una reducción del 90% en los flujos de trabajo manuales. En la conferencia de AI Tour de 2026, el vicepresidente de EY expresó su opinión de manera directa: “No implementamos la IA y luego nos preocupamos por la gobernanza, sino que primero creamos un marco de gobernanza y luego implementamos la IA”.

Atos: Un controlador unificado para 19,000 agentes.

Atos es la primera organización en implementar Microsoft 365 E7 (Frontier Suite) en todo el mundo, y ha desplegado Copilot en 56,000 empleados de 54 países. Simultáneamente, está ejecutando 19,000 agentes AI - desde departamentos de TI y de negocio hasta proyectos de clientes, todos están utilizando Foundry + Copilot Studio para crear agentes. La clave para que Atos lograra esto es “un controlador unificado”: Entra (identidad) + Defender (seguridad) + Intune (dispositivos) + Purview (regulación) + Agent 365 (gobierno de agentes). Esta integración es similar a la implementación en la industria financiera, que incluye “evaluación de seguridad de datos + evaluación de datos que salen del país + registro de algoritmos + auditoría + gobierno de modelos”, lo que es una arquitectura de gobierno en lugar de una herramienta de AI simple.

Nota: Entra es una plataforma de identidad de Microsoft, Defender es una solución de seguridad de Microsoft, Intune es una solución de gestión de dispositivos de Microsoft, Purview es una plataforma de gobernanza de datos de Microsoft y Agent 365 es una herramienta de gobierno de agentes de Microsoft.

La paradoja de la transformación organizativa de Microsoft. El informe de la Tendencia Laboral 2026 de Microsoft reconoce algo: “La velocidad de la transformación organizativa se retrasa con respecto al uso personal”. En su investigación con 20,000 usuarios de AI, 82% de los líderes planean extender la fuerza laboral con AI en 12-18 meses, pero solo 24% han completado la implementación en nivel empresarial. 81% de los líderes esperan que AI se integre en estrategias AI en gran medida o en gran medida - pero solo 24% han logrado esto. Esto significa que la mayoría de las empresas tienen un período de 12-18 meses entre “prepararse” y “hacerlo” y la normativa es el punto focal principal.

Fuente: Retroalimentación de Microsoft FY26 2026.7.28; Informe Anual de Tendencia Laboral de Microsoft 2026.5.5 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, PDF fuente principal); Análisis de Futurum Group 2026.1.26 (fuente secundaria).

Lección 1: Invertir en normativa es alta rentabilidad.

CodeRabbit proporciona una base clara para calcular el ROI: la tasa de problemas en código generado por IA es aproximadamente 1,7 veces mayor, y las vulnerabilidades de seguridad se reducen en un factor de 2,74. Esto implica:

Menos retrabajo (en el sector financiero, una revisión de cumplimiento normativo puede suponer de 2 a 4 semanas de retrabajo)
Menos incidentes de seguridad (una filtración de datos conlleva multas regulatorias y daño reputacional)
Menores costes de mantenimiento (una reducción de la deuda técnica del 40% es una cifra habitual)

Redactar un archivo de especificaciones del proyecto como CLAUDE.md o AGENTS.md es la acción de ingeniería con mayor retorno de inversión en la era de la IA. El caso de EY ofrece una conversión en el mundo real: 150.000 personas desplegando Copilot, con un ahorro de 250 millones de dólares. Conviene señalar que EY no ahorró porque “la herramienta fuera potente”, sino porque “las especificaciones hicieron que la herramienta materializara su valor”.

Segunda conclusión: incorporar las especificaciones a los procesos de la organización, en lugar de depender de individuos.

Si las especificaciones solo existen en la mente de un ingeniero senior, se pierden en cuanto hay rotación de personal. Es necesario consolidarlas en:

Documentación del repositorio (AGENTS.md / CLAUDE.md / constitution.md)
Puertas de control en CI (verificación automática del cumplimiento de las especificaciones)
Configuración compartida del equipo (el sistema de Skills permite que todo el equipo las utilice)

Que las especificaciones se conviertan en un activo de la organización, no en una habilidad individual. Esto es especialmente importante en el sector financiero: sus requisitos de cumplimiento, reglas de seguridad y reglas de negocio son activos a nivel organizativo, no la “experiencia” de un ingeniero concreto. Los 19 000 agentes de Atos pueden operar en 54 países porque la gobernanza no es “algo que alguien entiende”, sino “algo que el sistema impone”.

Lección 3: Los controles de acceso importan más que la velocidad.

Los cinco niveles de control de GitHub Spec Kit (constitution → specify → plan → tasks → implement), la regla de Claude Code de “no escribir código antes de que fallen los tests”, y la exigencia de Kiro de “no se puede arrancar sin un spec” — todos hacen lo mismo: poner un freno entre la IA y el resultado final. Cada paso deja un artefacto auditable (spec.md, plan.md, tasks.md) que puede ser rechazado o modificado antes de que se genere código.

Cuanto más autónoma es la IA, más necesita controles. El Change Advisory Board (CAB) en el sector financiero, los procesos de registro de algoritmos ante el EU AI Office y las evaluaciones del Esquema Nacional de Seguridad (ENS) son, en esencia, controles previos a la producción. El código generado por IA también necesita controles similares, solo que con otra forma. El 62% de equipos que “publican con confianza sin revisar” según el informe de New Relic 2026 está pagando esa confianza con una tasa de incidentes más alta (78%).

La primera fase consume más tiempo, pero el ROI es el más alto
En la mayoría de las instituciones financieras, las reglas están dispersas en documentos/correos/cerebros; la primera recopilación requiere de 3 a 8 semanas

Cuatro. Las tres fases reales de implementación en el primer semestre de 2026

Tomando el sector financiero como ejemplo, este camino de tres fases también aplica a otras industrias fuertemente reguladas. La práctica de EY y Atos en el primer semestre de 2026 corresponde precisamente a estas tres fases.

Fase 1: Inventario de reglas (2-4 semanas).

Es la fase que más tiempo requiere, pero también la de mayor retorno sobre la inversión. Se trata de localizar todas las reglas dispersas:

Requisitos de cumplimiento: la línea base mínima para el sector financiero en España = Esquema Nacional de Seguridad (ENS) en categoría alta o media-alta + GDPR Art. 46 (cláusulas contractuales tipo / SCC) para transferencias internacionales + EU AI Act para sistemas de IA de alto riesgo (crédito, seguros, antifraude) (si falta cualquiera de estos, no se despliega IA). Por encima de eso, están las reglas de reporte regulatorio del Banco de España y la CNMV, protección de información del cliente bajo LOPDGDD, restricciones de flujo de datos transfronterizo, y qué datos pueden exponerse a la IA.
Reglas de seguridad: gestión de contraseñas, estándares de cifrado, tratamiento de campos sensibles, requisitos de logging.
Reglas de negocio: umbrales de riesgo, condiciones de indemnización, límites de transacción, lógica de facturación.
Restricciones técnicas: interfaces de sistemas legacy, nomenclatura de bases de datos, versiones de frameworks.
Gobernanza de proveedores: cómo exigir contractualmente que los proveedores usen nuestros estándares, y cómo auditar el uso de IA por parte de los proveedores.

Escenario típico: durante la fase de inventario, una sociedad de valores descubre que las reglas están dispersas en innumerables documentos de Word, wikis de JIRA, correos personales y hojas de Excel — solo tras consolidarlo todo obtienen una lista estructurada de reglas. El enfoque de Atos es más sistemático: ellos desglosan directamente las reglas en cinco categorías —“cumplimiento, seguridad, negocio, tecnología y proveedores”—, cada una con su propio flujo de gobernanza, y las integran todas en el plano de control de Agent 365.

Esto no es una tarea técnica, es una tarea organizativa: tienes que reunir a los equipos de cumplimiento, seguridad y negocio, y poner por escrito las reglas que todos aceptan. La primera vez que se hace, una organización financiera suele tardar de 3 a 8 semanas — pero es un activo organizativo permanente.

Segunda fase: llevarlo al repositorio (1-2 semanas).

Las reglas consolidadas en la primera fase se documentan y se suben al repositorio. GitHub Spec Kit usa constitution.md, Claude Code usa CLAUDE.md, OpenAI Codex usa AGENTS.md, y Alibaba Qoder usa Spec Workflow. Los nombres de archivo difieren, pero el objetivo es el mismo: que la IA lo cargue en el momento en que abre el repositorio.

Estructura recomendada (forma dominante en el primer semestre de 2026):

Resumen del proyecto: qué hace este sistema y a quién sirve
Principios innegociables: líneas rojas de seguridad, cumplimiento normativo y negocio
Stack tecnológico y restricciones: qué framework, qué base de datos, qué estándar de interfaces
Estándares de código: convenciones de nomenclatura, estructura de directorios, cobertura mínima de pruebas (sin imponer el ritmo de TDD — basta con especificar el porcentaje de cobertura, las rutas obligatorias y las rutas prohibidas; TDD es un ritmo opcional para la organización, no un requisito impuesto por el estándar)
Reglas de negocio: lógica antifraude, reglas de transacción, reglas de facturación
Requisitos de cumplimiento: Esquema Nacional de Seguridad (ENS, marco público de certificación de seguridad por niveles exigido a entidades del sector público y proveedores de servicios críticos), transferencias internacionales bajo GDPR/LOPDGDD, reportes regulatorios al Banco de España/CNMV, y si los algoritmos generativos de IA requieren notificación al EU AI Office o a la AEPD
Normas de uso de IA: en qué escenarios se puede usar IA, en cuáles es obligatoria la revisión humana, reglas de transferencia de datos
Gobernanza de proveedores: cláusulas contractuales, mecanismos de auditoría, delimitación de responsabilidades

Anexo: esqueleto de CLAUDE.md para el sector financiero (unas 200 líneas, listo para fork y adaptación)

A continuación se presenta un esqueleto de CLAUDE.md para la modernización del sistema central de un banco comercial por acciones, organizado en el orden “principios innegociables → requisitos de cumplimiento → normas de uso de IA → reglas de negocio → restricciones de ingeniería”. Tu empresa no tiene que partir de cero — solo rellena los espacios vacíos con sus reglas específicas.

# CLAUDE.md — <nombre del sistema> — Normas de colaboración con IA

> Ámbito de aplicación: <nombre del sistema> v<versión>, todos los agentes de IA (Claude Code / Cursor / Copilot / Codex)
> que trabajen en este repositorio deben cumplir la presente especificación. Este documento lo mantiene el <órgano regulador> y se revisa trimestralmente.
> Última actualización: <YYYY-MM-DD>

## 1. Descripción del proyecto
- **Posicionamiento de negocio**: nombre del sistema core / segmentos de clientes atendidos / principales tipos de transacción
- **Cadena crítica**: transacción → control de riesgos → liquidación → conciliación → reporte regulatorio
- **Ventana de indisponibilidad**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (prohibido cualquier cambio en este intervalo)
- **Dependencias principales**: sistema upstream <nombre>, sistema downstream <nombre>, plataforma de reporte regulatorio

## 2. Principios innegociables (líneas rojas — toda violación implica rechazo del merge)

### 2.1 Líneas rojas de seguridad
- Contraseñas, claves y tokens deben pasar obligatoriamente por el KMS (sistema de gestión de claves): **prohibido el hardcoding**, **prohibida la impresión en logs**
- Los campos sensibles del cliente (DNI / número de tarjeta / CVV / teléfono) **deben almacenarse cifrados**; el texto en claro tiene prohibido llegar a la base de datos
- En los logs queda prohibido que aparezca: DNI completo, número de tarjeta completo, contraseña en claro, combinación de nombre + teléfono del cliente
- Las llamadas a interfaces externas deben pasar obligatoriamente por el API Gateway; están prohibidas las conexiones directas

### 2.2 Líneas rojas de cumplimiento
- Todo código generado por IA que implique acceso a datos del cliente debe indicar en la descripción del PR "acceso a datos: <campo>"
- Quedan prohibidas las transferencias de datos transfronterizas: **toda salida de datos debe pasar por el proceso de evaluación de transferencia transfronteriza de datos** (contactar al departamento de cumplimiento)
- Las decisiones algorítmicas (crédito / tarificación de seguros / antifraude) deben mantener una vía de revisión humana
- Todo cambio de modelo debe pasar por un registro de algoritmos; el número de registro debe citarse en la descripción del PR

### 2.3 Líneas rojas de negocio
- Toda modificación de umbrales de control de riesgos requiere la doble firma del responsable de riesgos y del responsable de negocio
- Cualquier operación que afecte fondos del cliente debe contar con diseño de idempotencia + rollback ante fallo
- Los cambios de límites de transacción, tarifas y parámetros de producto se gestionan en la plataforma de gestión de parámetros; prohibido hardcodear en el código

## 3. Stack tecnológico y restricciones
- **Lenguajes**: Java 17 (núcleo) / Kotlin (módulos nuevos) / SQL (base de datos)
- **Framework**: Spring Boot 3.x + Spring Cloud Alibaba
- **Base de datos**: OceanBase 4.x (modo compatible con MySQL), **prohibido el uso de claves foráneas**
- **Normas de interfaz**: internamente todo en gRPC; interfaces externas en OpenAPI 3.0; RESTful solo para interfaces administrativas
- **Convenciones de nomenclatura**: clases Java en PascalCase, métodos en camelCase, constantes en UPPER_SNAKE; tablas `t_<dominio de negocio>_<entidad>`; índices `idx_<tabla>_<campo>_<orden>`
- **Estructura de paquetes**: `com.<empresa>.<dominio de negocio>.<subdominio>.<capa>` (p. ej. `com.bank.pay.tx.core.service`)

## 4. Normas de código
- **Cobertura mínima de pruebas**: cadena crítica ≥ 80 %, clases utilitarias ≥ 60 %, todo nuevo código entregado por PR debe incluir pruebas
- **Rutas obligatorias de prueba**: todos los controllers deben disponer de pruebas de integración (incluidos los caminos de fallo); todas las ramas de enums deben tener pruebas unitarias
- **Rutas prohibidas**: queda prohibido modificar el directorio `<módulo de deuda histórica>` — primero se debe crear una capa de adaptación
- **Gestión de dependencias**: cualquier nueva dependencia de terceros debe pasar por un análisis SCA + validación de seguridad

## 5. Reglas de negocio (por dominio)
### 5.1 Transacciones
- Límite unitario: <importe>; límite diario: <importe>; los excesos se gestionan por aprobación manual
- Ventana de tiempo de transacción: <hora> ~ <hora>
- Detección de transacciones duplicadas: dentro de <ventana temporal>, mismo <campo> se considera duplicado

### 5.2 Control de riesgos
- Prioridad de coincidencia con listas negras: lista interna → listas difundidas por el regulador (CBIRC / Banco Popular de China) → bloqueo judicial
- Umbral de salida del modelo antifraude: <puntuación>; por encima, es obligatoria la doble revisión humana

### 5.3 Facturación
- Todo cambio de tarifa debe llevar un número de versión + fecha de entrada en vigor
- Los pedidos históricos se calculan según la tarifa vigente en su fecha de efecto, sin retroactividad

## 6. Requisitos de cumplimiento
- MLPS Nivel 3 (等保三级, Multi-Level Protection Scheme, certificación china de seguridad por niveles obligatoria para sistemas de información): <organismo de evaluación>, <fecha de la próxima evaluación>
- Evaluación de transferencia transfronteriza de datos (数据出境评估): ámbito de aplicación (solo módulos de negocio transfronterizo)
- Registro de algoritmos (算法备案): ámbito de aplicación (crédito / tarificación de seguros y otros algoritmos críticos), número de registro `<nº registro>`
- Reportes regulatorios (监管报送): tabla de correspondencia de campos del <órgano regulador> en `<ruta>`

## 7. Normas de uso de IA
- **Escenarios en los que se permite usar IA**: plantillas CRUD, generación de pruebas unitarias, borradores de documentación, sugerencias de optimización SQL
- **Escenarios que requieren revisión humana obligatoria**: lógica de control de riesgos, reglas de facturación, control de permisos, cifrado/descifrado, datos transfronterizos
- **Escenarios prohibidos para la IA en solitario**: materiales de aprobación del CAB (Change Advisory Board), ejecución de cambios en producción, respuesta a incidentes
- **Reglas de salida de datos**: datos de entrenamiento / prompts / logs de salida — ninguno puede salir del país; se prioriza la versión de despliegue localizado (<proveedor>)
- **Requisitos de auditoría**: todo código generado por IA debe marcarse en la descripción del PR como "asistencia IA: <nombre de la herramienta>"

## 8. Gobernanza de proveedores
- **Admisión de proveedores**: deben aportar informes SOC 2 / ISO 27001; los modelos de IA deben aportar su model card
- **Cláusulas contractuales**: propiedad de los datos, explicabilidad del modelo, cláusulas de salida, derecho de auditoría
- **Mecanismo de auditoría**: auditoría trimestral del uso de IA por parte de los proveedores; auditoría mensual para los proveedores de alto riesgo

## 9. Gobernanza y actualización
- **Propietario**: <órgano regulador> (cumplimiento + seguridad + arquitectura + negocio)
- **Frecuencia de actualización**: revisión trimestral; los cambios urgentes pasan por la vía rápida (doble firma + publicación de 24 h)
- **Registro de cambios**: ver `CLAUDE_CHANGELOG.md`
- **Manejo de infracciones**: 1.ª infracción = advertencia + formación obligatoria; 2.ª infracción = suspensión del uso de herramientas de IA; 3.ª = retirada de permisos

Este esqueleto no es una “respuesta estándar”, es una “plantilla para rellenar”. Lo que importa no es cuánto escribes, sino qué pones en cada hueco — los espacios en blanco revelan exactamente aquello que tu empresa “no tiene claro”.

Un caso típico: el CLAUDE.md de un banco comercial define reglas específicas para el manejo de contraseñas — cuando el código generado por IA involucra contraseñas, debe llamar a la API interna de gestión de claves, y queda prohibido el hardcodeo. Este tipo de reglas representa una gran proporción de los motivos por los que se rechazan los entregables en las revisiones de cumplimiento.

Un campo nuevo e importante en el primer semestre de 2026 son las Skills/definiciones de flujo de trabajo — ya no es solo documentación, es una cadena de herramientas que la IA puede invocar. El sistema de Skills de Claude Code (que entró al marketplace oficial de Anthropic en febrero de 2026, con 112 000 estrellas en GitHub) convierte tareas como “leer una hoja de Excel”, “generar SQL” o “ejecutar una migración de datos” en flujos de trabajo compartibles. Esta es la evolución clave de la gobernanza en el primer semestre de 2026: la gobernanza no es solo una restricción, es un flujo de trabajo ejecutable.

Tercera fase: institucionalización (continua).

Escribir la norma no es el final, es el comienzo. Hay que convertirla en parte de los procesos de la organización:

Integración con CI como puerta de control: verificación automática de que el código cumple la norma (por ejemplo, detectar contraseñas hardcodeadas o campos sensibles sin cifrar).
Configuración compartida para el equipo: usar el sistema de Skills para que todo el equipo trabaje con el mismo estándar.
Mecanismo de actualización periódica: si cambian las reglas, la norma debe cambiar también (revisión trimestral).
Métricas y retroalimentación: hacer seguimiento de la tasa de defectos en código generado por IA, la tasa de aprobación en revisiones de cumplimiento y la tasa de retrabajo.
Gobernanza de agentes: extender la gobernanza de personas a la de agentes de IA — lo que Atos está haciendo con Agent 365 es precisamente llevar esto a nivel de “sistema” en lugar de “individuo”.

EY y Atos convirtieron la tercera fase en “capacidad organizacional” en el primer semestre de 2026. Los 2,5 millones de horas ahorradas por EY se deben a que la primera y la tercera fase se hicieron bien — la segunda fase solo tradujo las reglas a documentos legibles por IA.

Cinco. Variante de alta regulación: tres enfoques de ingeniería para incrustar el cumplimiento

En sectores altamente regulados como banca, telecomunicaciones y salud, la implementación basada en normas enfrenta un reto adicional: el cumplimiento no es un complemento externo al proceso, sino algo que va incrustado en el código. Los tres enfoques siguientes son formas de incrustar cumplimiento validadas en el primer semestre de 2026, y los CIO y responsables de transformación digital pueden usarlos como referencia directa al diseñar su organización.

5.1 Representantes de cumplimiento integrados en los equipos de flujo: que el cumplimiento esté “presente”, no que sea una “aprobación a posteriori”

El enfoque tradicional: el equipo de negocio escribe código y el equipo de cumplimiento lo revisa después — cuando la revisión detecta problemas, el código ya lleva dos semanas en producción, y rehacerlo cuesta de 2 a 4 semanas. El problema de fondo es que el cumplimiento llega al final del proceso.

El nuevo enfoque: incrustar un representante de cumplimiento en cada equipo de flujo (stream-aligned team), con una estructura de doble dependencia: “línea sólida” hacia el departamento de cumplimiento y “línea punteada” hacia el equipo de negocio. El diseño concreto:

Asignación de personal: un representante de cumplimiento por cada 6-8 equipos de flujo, adscrito al departamento de cumplimiento pero con puesto físico en el equipo de negocio — no es una “comisión de servicios” puntual
KPI en línea punteada: el 50% del peso de la evaluación del representante de cumplimiento recae en la “tasa de defectos de cumplimiento” y la “tasa de aprobación a la primera” del equipo de negocio, no solo en la “cobertura de auditoría” del departamento de cumplimiento
Intervención temprana: el representante de cumplimiento participa en el daily stand-up (con una vez por semana basta), en las revisiones de PR, y el código generado por IA debe pasar por el representante de cumplimiento antes de fusionarse — no descubrirlo después del merge y tener que remendarlo
Soporte de herramientas: el representante de cumplimiento utiliza Skills de listas de verificación de cumplimiento en lugar de revisar manualmente punto por punto

Escenario típico: un banco comercial a nivel nacional pilotó en el primer semestre de 2026 tres equipos de flujo con representantes de cumplimiento integrados, reduciendo la tasa de rechazo por cumplimiento en código de IA del 35 % al 8 % — el punto clave no es que el cumplimiento “vigile más estricto”, sino que “vigile más temprano”. Lo esencial de este enfoque es que los incentivos indirectos de los representantes de cumplimiento estén alineados con los objetivos de negocio — si el KPI del representante de cumplimiento sigue dependiendo únicamente de las tareas asignadas por el departamento de cumplimiento, la integración está destinada al fracaso.

5.2 El cumplimiento como enabling team: convertir restricciones en affordances

Enfoque tradicional: el equipo de cumplimiento actúa como “guardián de la puerta”, y el equipo de negocio lo percibe como “el que crea problemas”. Ambos lados juegan un juego de suma cero.

Nuevo enfoque: el equipo de cumplimiento se reestructura siguiendo el modelo de enabling team de Team Topologies — no escribe código directamente ni revisa pull requests, pero proporciona tres cosas para que el equipo de negocio pueda “cumplir por sí mismo”:

Verificaciones de cumplimiento integradas en el pipeline de CI: Los puntos de cumplimiento de alta frecuencia —como contraseñas hardcodeadas, campos sensibles en texto plano, transferencias transfronterizas de datos y puntos de decisión algorítmica— se convierten en compuertas obligatorias en GitHub Actions / GitLab CI. Cuando el equipo de negocio abre un PR, se dispara la verificación automática y, si no cumple, el pipeline falla directamente — sin necesidad de que un delegado de cumplimiento lo revise manualmente.
Convertir los requisitos regulatorios en affordances (restricciones reactivas al entorno): Por ejemplo, al desarrollar funciones que involucran datos de clientes, el plugin del IDE muestra un aviso como “este campo debería invocar KMS”; al escribir logs, se detecta automáticamente si contienen información sensible y se genera una alerta. El cumplimiento se convierte en “una acción natural durante el desarrollo”, no en “enterarse de qué se violó justo antes del despliegue”.
Biblioteca compartida de Skills + formación en cumplimiento: El equipo de cumplimiento mantiene una colección de “Skills de cumplimiento” que se invoca directamente al incorporar nuevos empleados o al cambiar de equipo — transformando el conocimiento de cumplimiento de “documentación” a “herramientas ejecutables”.

Caso típico: un banco regional implementó en el primer semestre de 2026 compuertas de cumplimiento en CI + avisos de cumplimiento en el IDE, reduciendo el tiempo promedio por persona en la revisión de cumplimiento de código de IA de 45 minutos por revisión a 8 minutos. El punto clave no es que la “revisión de cumplimiento” sea más rápida, sino que el código generado por IA “no comete errores” desde el inicio.

5.3 Cumplimiento de doble velocidad: segmentación según el ritmo del negocio

Un último apunte: el cumplimiento no debe ser “uniforme”. Hay que dividir las reglas en dos niveles según el riesgo:

Reglas de alto riesgo (que involucran fondos de clientes, decisiones algorítmicas, datos transfronterizos o líneas rojas del Esquema Nacional de Seguridad y del EU AI Act) requieren control estricto: revisión humana obligatoria, doble verificación por IA y registro en el Change Advisory Board (CAB).
Reglas de bajo riesgo (plantillas CRUD, código de utilidades, generación de documentación) requieren control de autoservicio: basta con la verificación automática del CI, sin necesidad de revisión humana.

El plano de control de Agent 365 de Atos es esencialmente esta estratificación: diferentes niveles de agentes se vinculan a diferentes requisitos de gobernanza. Al estratificar las reglas de cumplimiento por riesgo, el equipo de negocio siente que “cumplir no es obstaculizar todo”.

La conclusión de estos tres puntos: integrar el cumplimiento no es añadir un proceso, es rediseñar la estructura y los incentivos del equipo de flujo. Si tu departamento de cumplimiento sigue en el modo de “revisión después del hecho”, la implementación de la normativa dirigida por especificaciones se atascará en la etapa más difícil: la de “institucionalización”. El departamento de cumplimiento debe transformarse primero, antes de que la normativa dirigida por especificaciones pueda funcionar sin problemas para el equipo de negocio.

6. Preguntas que quizás quieras hacer

“Ya tenemos estándares de codificación, ¿en qué se diferencia esto?”

Los estándares de codificación manage how to write code; la normativa dirigida por especificaciones manage how to collaborate with AI. Los estándares de codificación no incluyen reglas de negocio, requisitos de cumplimiento ni políticas de uso de IA. La normativa dirigida por especificaciones hace explícito todo el proceso de colaboración entre humanos y AI, no es una guía de estilo de código.

“¿Escribir especificaciones ralentiza el desarrollo?”

A corto plazo, sí. A largo plazo, no. Los datos de CodeRabbit lo dejan claro: el código generado por IA sin restricciones tiene aproximadamente 1,7 veces más riesgo de defectos y 2,74 veces más vulnerabilidades de seguridad. En el sector financiero, una sola revisión de cumplimiento normativo puede costar de 2 a 4 semanas de retrabajo — evitar una sola de esas revisiones ya compensa un mes entero escribiendo especificaciones. Los 250 millones de dólares que EY logró ahorrar son la prueba real de que esto, convertido en capacidad organizativa, funciona.

“¿Y si en nuestro equipo nadie sabe escribir especificaciones?”

No hace falta partir de cero. GitHub Spec Kit, Claude Code Superpowers y AWS Kiro ya incluyen plantillas. Solo tienes que rellenar las reglas específicas de tu organización — en su mayoría, reglas de cumplimiento y seguridad que los departamentos de compliance y seguridad ya tienen redactadas; simplemente nunca las han puesto donde la IA pueda leerlas.

“Con tantas herramientas de IA, ¿cuál elijo?”

No es importante. Elegid las que ya estéis usando. La gobernanza por especificaciones no está ligada a una herramienta concreta: CLAUDE.md funciona en Claude Code, Cursor y Codex; AGENTS.md corre en el ecosistema de OpenAI; constitution.md es independiente del modelo. Lo clave es escribir la especificación, no cambiar de herramienta. EY despliega en el ecosistema de Microsoft, Atos también. La elección de herramienta es solo la superficie; la uniformidad del marco de gobernanza es lo que de verdad importa.

“En agosto de 2026, la EU AI Act entra en pleno vigor. ¿Nos afecta?”

Sí. La EU AI Act entra en plena aplicación el 2 de agosto de 2026, con requisitos obligatorios para sistemas de IA de alto riesgo (incluidos crédito, fijación de precios de seguros, selección de empleo e infraestructuras críticas): gestión de riesgos (Art. 9), gobernanza de datos (Art. 10), transparencia documental (Arts. 11-13), supervisión humana (Art. 14) y precisión/robustez (Art. 15). Las multas por incumplimiento alcanzan hasta 35 millones de euros o el 7% de la facturación global. Para las empresas chinas que se expanden al extranjero, el mercado europeo es una asignatura obligatoria; para las empresas nacionales, el marco de la EU AI Act es también el estándar más referenciado a nivel mundial — puedes no estar directamente sujeto a ella, pero difícilmente puedes evitar su efecto de transmisión sobre tus proveedores, socios y operaciones transfronterizas (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

“Comparativa nacional: la UE regula la IA, ¿y nosotros qué regulamos?”

En China, la gobernanza de la IA generativa sigue el trío de “registro de algoritmos + revisión de corpus + evaluación de seguridad”, con el Reglamento Provisional para la Gestión de Servicios de IA Generativa (vigente desde agosto de 2023) como instrumento central. La mayor diferencia entre ambos marcos no radica en el detalle de las disposiciones, sino en la filosofía legislativa:

Dimensión	EU AI Act	Medidas de Gestión de Servicios de IA Generativa de China
Naturaleza jurídica	Regulación horizontal (aplica a todos los sistemas de IA)	Regulación vertical (centrada en servicios de IA generativa)
Clasificación de riesgo	4 niveles (inaceptable / alto / limitado / mínimo)	2 niveles (relacionados con la seguridad de la opinión pública / uso comercial general)
Momento de supervisión	Ex ante (registro desde el desarrollo)	Ex post (registro tras el lanzamiento + registro del algoritmo)
Transparencia	Alta (exige resumen de fuentes de datos de entrenamiento y model cards)	Media (exige cumplimiento en corpus, pero no obliga a revelar fuentes)
Límite de sanciones	7 % de los ingresos globales o 35 millones de euros	Suspensión del servicio / multas (generalmente múltiplos de las ganancias ilícitas)
Ámbito de aplicación	Todas las empresas que superen el umbral de ingresos globales	Todas las entidades que presten servicios dentro del territorio de China

En la práctica, los sistemas de IA de las entidades financieras españolas y europeas suelen estar sujetos simultáneamente a tres marcos normativos —el EU AI Act (capa horizontal de IA, con la AEPD y el EU AI Office como supervisores para sistemas de alto riesgo) + las normativas sectoriales del Banco de España y la CNMV (capa de negocio, incluida la Circular 3/2024 sobre gobernanza de IA en servicios financieros) + el GDPR / LOPDGDD para protección de datos, junto con el Esquema Nacional de Seguridad (ENS) para entidades del sector público y proveedores de servicios críticos (CCN). Esto significa que, para hacer gobernanza basada en normas dentro del marco europeo, hay que combinar el cumplimiento del EU AI Act con la supervisión nacional de la AEPD y, cuando aplique, la certificación ENS, incorporando al archivo CLAUDE.md las tres líneas clave: “gestión de riesgos algorítmicos, transferencias internacionales bajo SCC, y reporte regulatorio”.

Para empresas europeas: el paquete de cuatro elementos del EU AI Act —“gestión de riesgos, gobernanza de datos, transparencia documental y supervisión humana”— se ha convertido en el referente global. Varias autoridades nacionales (AEPD en España, CNIL en Francia, Garante en Italia) ya están publicando guías de implementación que aplican este marco con granularidad local. Redactar hoy una normativa compatible con el EU AI Act garantiza simultáneamente alineamiento con GDPR/LOPDGDD y con la supervisión nacional de la AEPD para los próximos tres años (anuncios de la AEPD 2025-2026; EU AI Act compliance guide junio 2026).

7. Implicaciones para decisores

Implicación 1: redactar una especificación de proyecto en CLAUDE.md/AGENTS.md es la acción de ingeniería con mayor retorno de inversión en la era de la IA.

Su inversión es de 3 a 8 semanas de organización más 1 a 2 semanas de documentación. Su retorno: el límite superior del riesgo de defectos se multiplica por aproximadamente 1,7, las vulnerabilidades de seguridad se reducen 2,74 veces y la tasa de retrabajo cae más de un 40%. En el sector financiero, evitar un solo retrabajo de revisión de cumplimiento (de 2 a 4 semanas) ya cubre ese coste. Los 150.000 empleados de EY que desplegaron Copilot ahorraron 250 millones de dólares, pero la premisa fue contar primero con estándares definidos.

Lección 2: La gobernanza por estándares es una capacidad organizativa, no una decisión de herramienta.

Da igual si eliges GitHub Spec Kit o Claude Code; lo importante es si has definido “cómo colabora nuestra organización con la IA”. Sin eso, la mejor herramienta solo sirve para que el equipo genere más deuda técnica a mayor velocidad.

Lección 3: Incorpora los estándares a los procesos de la organización, no los dejes en manos de individuos.

Si el estándar vive solo en la cabeza de un ingeniero senior, se pierde en cuanto hay rotación de personal. Hay que consolidarlo en la documentación del repositorio, en los controles de CI, en las configuraciones compartidas del equipo y en las plataformas de gobernanza de agentes. El estándar debe ser un activo de la organización, no una habilidad personal. Los 19.000 agentes de Atos operan en 54 países porque la gobernanza no es “algo que alguien entiende”, sino “algo que el sistema impone”.

Lección 4: Los controles de calidad importan más que la velocidad.

Las cinco etapas de control de GitHub Spec Kit, la regla de Superpowers de “no escribir código hasta que fallen los tests”, y la exigencia de Kiro de “no se puede iniciar sin un spec” — todas estas prácticas añaden un “freno” entre la IA y el resultado final. Cuanto mayor es la capacidad de la IA, más necesaria es la gobernanza por adelantado. La tasa de incidentes del 78 % en el informe de New Relic 2026 es el precio que pagan los equipos que “despliegan sin revisar”. Los CIO del sector financiero lo entienden perfectamente: sus Change Advisory Boards, los flujos de registro de algoritmos y las evaluaciones ENS son controles previos a la producción. El código de IA también necesita controles similares, y deben ser aún más anticipatorios.

Autochequeo inverso (sin maquillar las respuestas): ¿el código que genera la IA en su organización se devuelve con frecuencia desde la revisión de cumplimiento? ¿Cuál fue el último incidente causado por código de IA? Si le preguntas al responsable técnico “¿cómo colaboramos con la IA?”, ¿podría entregar un documento? Si no puedes responder al menos una de estas tres preguntas, la gobernanza por especificaciones aún no está implantada — primero escribe las especificaciones, luego compra las herramientas.

Tres preguntas de coaching para los decisores

Te dejamos tres preguntas para abrir la conversación con tu equipo — no son un checklist, son preguntas que puedes llevar directamente a la discusión:

“Si mañana todas las herramientas de IA desaparecieran, ¿cuánto caería la calidad del código de tu equipo?” — Esta pregunta revela el valor real de la gobernanza basada en especificaciones: si la respuesta es “caería significativamente”, significa que tus estándares aún no están consolidados; si es “apenas cambiaría”, la gobernanza por especificaciones ya está funcionando.
“En vuestro proyecto de gobernanza por especificaciones, ¿el departamento de cumplimiento actúa como ‘guardián’ o como ‘facilitador’?” — Si la respuesta es “guardián”, tu velocidad de implementación quedará estrangulada por los cuellos de botella de revisión; si es “facilitador”, ya estáis en el camino correcto descrito en la sección 5.2.
“¿Cómo cambiará el tamaño de tu equipo en 12-18 meses?” — La respuesta del WTI 2026 de Microsoft es que el 82% de los líderes utilizarán agentes de IA para “ampliar” su fuerza laboral. Si tu respuesta es “no cambiará”, o tu negocio no está creciendo, o tu diseño organizativo no está aprovechando los beneficios de la gobernanza por especificaciones.

No hay respuestas estándar para estas tres preguntas. Pero la dirección de la respuesta importa más que la respuesta en sí.

Siguientes pasos

Este es el sexto artículo de la serie “La transformación de la ingeniería de software en la era de la IA”. Hemos recorrido el camino desde Conway (la organización determina la arquitectura) hasta Team Topologies (cómo diseñar la organización), pasando por el desplazamiento de los cuellos de botella (el cuello de botella está en la verificación, no en la codificación), y hoy hablamos de la gobernanza por especificaciones (usar documentación para restringir el comportamiento de la IA).

En el próximo artículo (el séptimo), veremos la infraestructura subyacente que sostiene todo esto: el protocolo MCP (Model Context Protocol). Por qué el protocolo open source de Anthropic se ha ganado el apodo de “el USB-C de la IA”, por qué OpenAI, Google y Microsoft se han sumado todos a la iniciativa, y cómo está haciendo posible la interoperabilidad entre múltiples herramientas y agentes.

¿Quieres llevar este enfoque a tu empresa?

Cuando la gobernanza por normas (spec-driven) aterriza en una organización, los problemas que realmente hay que resolver suelen ser muy concretos: cómo consolidar las reglas core en archivos CLAUDE.md / AGENTS.md, cómo adaptar el código legacy a las nuevas normas, cómo integrar el cumplimiento normativo, y con qué métricas validar el piloto.

Ofrecemos tres modalidades de colaboración:

Formación in-company: trabajamos sobre proyectos reales de tu empresa para definir los documentos de normas, diseñar los controles en el CI, trazar la ruta de integración del cumplimiento y montar el mecanismo de gobernanza.
Consultoría específica: nos centramos en una decisión concreta, como “¿deberíamos empezar por escribir un CLAUDE.md / AGENTS.md?” o en priorizar la remediación del código legacy para alinearlo con las normas.
Sesiones para dirección y conferencias: sobre herramientas de programación con IA, gobernanza por normas, gestión organizativa y empresas frontera (Frontier Firms).

El artículo puede ofrecer un marco general, pero la implementación concreta requiere rediseñarse según los requisitos de cumplimiento de cada empresa, los límites regulatorios, la madurez de la ingeniería y los flujos de entrega existentes. Para colaboraciones, contacte a coach@iaiuse.com.

Lectura recomendada: Metodología del Letrero Visible v1.0 (Aprendiendo IA Lentamente 187), que presenta de forma sistemática el marco de 7 pasos para la transformación empresarial con IA.

Sobre esta serie

“La transformación de la ingeniería de software en la era de la IA” es una serie de investigación dirigida a CIO, CDO, CTO y líderes de transformación digital en sectores como telecomunicaciones, finanzas, manufactura y comercio electrónico. Consta de 18 artículos que abordan cómo las herramientas de programación con IA, la gobernanza basada en estándares y la gobernanza organizacional impactan los flujos de entrega de software, la estructura organizativa y la madurez de la ingeniería.

La serie realiza un seguimiento continuo de artículos académicos, materiales de proveedores e informes de la industria. El repositorio de investigación acumula más de 200 referencias, y los juicios clave están etiquetados con su nivel de evidencia, distinguiendo entre hechos verificados, afirmaciones de proveedores, observaciones de la industria y razonamientos del autor.

Cuento con casi 8 años de experiencia en consultoría para grandes empresas y análisis de negocio. Trabajé en IBM, participando en proyectos para los sectores de telecomunicaciones, finanzas, seguros y manufactura. Posteriormente, continué en el desarrollo de productos para operadores, productos de internet y aplicaciones de IA, en áreas como análisis de requisitos, diseño de productos e implementación transversal entre equipos.

Esta serie de juicios sobre gobernanza impulsada por normas, gobernanza organizativa e ingeniería proviene de estas prácticas, y se contrasta con investigación pública y casos de la industria. Todo el contenido relacionado con proyectos específicos ha sido anonimizado; algunos escenarios sectoriales corresponden a ejercicios de razonamiento sobre problemas típicos, y las bases correspondientes se indican en las referencias al final.

Detrás de esta cuenta hay en realidad un equipo pequeño: yo y 1 o 2 colegas con quienes colaboro a largo plazo, repartiéndonos la investigación de herramientas de programación con IA, el análisis de casos de gobernanza organizativa y las conversaciones de coaching. La mayoría de los proyectos en los que “acompañamos a empresas a sortear dificultades” fueron entregados conjuntamente por nosotros. Los límites de cumplimiento de los clientes y los nombres de personas siguen sin mencionarse; el anonimato se reserva para dejar espacio a futuros colegas con quienes trabajemos.

Referencias (todas verificadas, con nivel de evidencia indicado por entrada)

CodeRabbit (2025.12). State of AI vs Human Code Generation Report. El código generado por IA presenta 1,7 veces más problemas que el código humano (10,83 frente a 6,45 problemas por pull request), con una ratio de 1,75× en lógica/corrección, 1,64× en calidad de código, 1,57× en seguridad, 1,88× en manejo de contraseñas y 2,74× en XSS. Nivel de evidencia: primario. Fuente: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263
The Register (2025.12.17). Cobertura del informe completo de CodeRabbit: análisis de 470 pull requests de proyectos open source; los PR con colaboración de IA contienen 10,83 problemas frente a 6,45 en los puramente humanos. Nivel de evidencia: secundario. Fuente: misma URL anterior.
CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap”: 2026 marca el punto de inflexión entre la velocidad de generación de código y la calidad y gobernanza del mismo. Nivel de evidencia: secundario. Fuente: https://tfir.io/ai-code-quality-2026-guardrails
New Relic (2026). The 2026 State of AI Coding Report. El 78% de los equipos reporta más incidentes tras implementar código generado por IA; el 62% de los líderes técnicos admite que sus equipos “despliegan con confianza sin revisar” código de IA; el 96% considera la observabilidad un requisito indispensable. Nivel de evidencia: primario (informe de proveedor). Fuente: https://newrelic.com/resources/report/2026-state-of-ai-coding
Informe Anual del Índice de Tendencias Laborales de Microsoft 2026 (5 de mayo de 2026). Encuesta a 20 000 trabajadores que usan IA, en 10 países; el 82 % de los líderes planea ampliar su fuerza laboral con agentes de IA en los próximos 12 a 18 meses; el 81 % prevé una integración de agentes de IA de moderada a alta; el 24 % ya los ha desplegado a nivel empresarial; el 49 % de las conversaciones con Copilot respaldan el trabajo cognitivo; el 58 % de los usuarios de IA afirma haber logrado “cosas que no podía hacer hace un año”, cifra que asciende al 80 % entre los Profesionales de Frontera. Nivel de evidencia: uno. Fuente: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf
Retrospectiva FY26 de Microsoft: de la experimentación con IA a la transformación de frontera (28 de julio de 2026). EY implementó Microsoft 365 Copilot para 150,000 empleados, ahorrando 2.5 millones de horas y aproximadamente 250 millones de dólares; la expansión a 400,000 empleados globales logró un 95% de aceleración, una reducción del 37% en costos de operaciones financieras y hasta un 90% menos de flujos de trabajo manuales. Atos desplegó Copilot en 56 países para 56,000 empleados, junto con 19,000 agentes de IA, unificando el plano de control de identidad, seguridad, cumplimiento y gobernanza. Nivel de evidencia: nivel uno (revisión oficial de Microsoft). Fuente: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation
Colaboración estratégica entre Atos Group y Microsoft (9 de junio de 2026). Atos implementa Microsoft 365 E7 (Frontier Suite) para 56 000 empleados en 56 países, junto con 19 000 agentes de IA; unifica el plano de control de Entra/Defender/Intune/Purview/Agent 365. Nivel de evidencia: nivel uno (comunicado de prensa conjunto de ambas partes). Fuente: https://news.microsoft.com/source/2026/06/09/atos-group-and-microsoft-expand-strategic-collaboration-to-scale-secure-agentic-ai-across-atos-group-workforce-and-clients
GitHub Spec Kit (código abierto en septiembre de 2025, evolución en el primer semestre de 2026). Proceso de 5 fases con compuertas de aprobación /speckit.constitution → /specify → /plan → /tasks → /implement, más /clarify /analyze; independiente del modelo (compatible con Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code). Nivel de evidencia: 1. Fuente: https://github.com/github/spec-kit
AWS Kiro (lanzado en julio de 2025, evolución en el primer semestre de 2026). Flujo de trabajo en tres fases: requisitos → diseño → tareas; el spec dispara acciones de agente predefinidas; sin spec, no se puede iniciar. Nivel de evidencia: 1. Fuente: https://kiro.dev/
OpenAI Codex + AGENTS.md + Skills (2025-2026). Codex alcanzó más de 5 millones de usuarios activos semanales en junio de 2026, de los cuales el 20% no son desarrolladores; AGENTS.md + Skills conforman un sistema de instrucciones combinables. Nivel de evidencia: primario (anuncio oficial de OpenAI). Fuente: https://developers.openai.com/codex/skills
Claude Code (Anthropic, primer semestre de 2026). Sistema basado en CLAUDE.md + .claude/rules/ + Skills; entró al mercado oficial de Anthropic en febrero de 2026; el repositorio de Skills en GitHub alcanzó 112,000 estrellas; la ronda de financiación Serie G de febrero de 2026 reveló ingresos anualizados de 2,500 millones de dólares. Nivel de evidencia: primario. Fuente: https://code.claude.com/docs/en/claude-directory
JetBrains AI Pulse Survey (2026.1). Encuesta a más de 10,000 desarrolladores profesionales a nivel global, localizada en 8 idiomas; Claude Code alcanza un CSAT del 91% y un NPS de 54 (el más alto de la industria); adopción de Claude Code en el lugar de trabajo del 18% (creció 6 veces desde el 3% en 9 meses), 24% en Norteamérica; Copilot tiene un 29% de adopción en el lugar de trabajo pero su crecimiento se ha estancado; Cursor 18%. Nivel de evidencia: nivel uno. Fuente: https://www.jetbrains.com/lp/tools/ai-tools/
Pragmatic Engineer Newsletter (2026.2). Encuesta a 15,000 desarrolladores; el 46% eligió a Claude Code como su “favorito”, Cursor 19%, Copilot 9%. Nivel de evidencia: nivel uno. Fuente: https://newsletter.pragmaticengineer.com/
Alibaba Qoder (2025.8 → 2026.7). Lanzado por Alibaba en agosto de 2025; el 15 de mayo de 2026, Qoder 1.0 se actualizó a Autonomous Agent Development Workbench; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; el 28 de mayo de 2026, Cloud Agents (entorno de ejecución de agentes gestionados); el 21 de julio de 2026, Qoder Security; en mayo de 2026, más de 5 millones de usuarios globales; integración con CLI de Microsoft Teams; el 20 de mayo de 2026, Tongyi Lima pasó a llamarse Qoder CN. Nivel de evidencia: primario. Fuente: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525
vibecoding.app / thebcms.com / tfir.io (1.er semestre de 2026). Comandos de cinco fases de Spec Kit, comparativa de herramientas SDD, notación EARS. Nivel de evidencia: secundario (evaluaciones de terceros). Fuente: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development
EU AI Act / Code of Practice (plena aplicación el 2.8.2026). Los sistemas de IA de alto riesgo deben cumplir antes del 2.8.2026; los modelos GPAI existentes tienen plazo hasta el 2.8.2027; multas de hasta 35 millones de euros o el 7% de la facturación global; Arts. 9-15: gestión de riesgos, gobernanza de datos, transparencia documental, supervisión humana, precisión y robustez. Nivel de evidencia: primario (regulación + análisis de cumplimiento secundario). Fuente: https://artificialintelligenceact.eu/code-of-practice-overview; https://www.surecloud.com/resource-hub/eu-ai-act-complete-compliance-guide
Qodo State of AI Code Quality Report (2025). El 44% de los problemas se origina por falta de contexto. Nivel de evidencia: secundario (informe de proveedor). Fuente: https://www.qodo.ai/reports/state-of-ai-code-quality/