AIMeticulously 深度探索AI转型之路 2026-08-25T16:16:00.000Z https://iaiuse.com/ Richardson Hexo 【Revolucionando lo Tradicional】 Cadena de Pensamiento CoT: Convierte a tu IA de simple procesador de datos en un asesor inteligente—Aprende IA despacio 043 https://iaiuse.com/es/posts/70bfc291 2026-08-25T17:11:17.921Z 2026-08-25T16:16:00.000Z Introducción
  • Se dice que no saber redactar buenos prompt es debido a no entender CoT.
    • ¿Qué es CoT? ¿Cadena de Pensamiento?
  • Se dice que si le dices a la IA que lo haga paso a paso, mejorará mucho.
    • ¿Es esta una fórmula mágica, tan simple como eso?

I. Introducción: Nuevos Desafíos para la Toma de Decisiones Empresariales en la Era de IA

Imagina que eres el CEO de una empresa y sobre tu escritorio descansa un último informe de investigación de mercado, repleto de datos, gráficos y análisis. Necesitas comprender rápidamente las tendencias del mercado, las estrategias de los competidores y el feedback de los usuarios para tomar decisiones comerciales clave. Sin embargo, ante tanta información ¿te sientes abrumado? Las herramientas tradicionales de análisis empresarial sólo ofrecen datos y gráficos, careciendo de capacidad de análisis y razonamiento profundos, lo que dificulta la identificación de la lógica subyacente en los datos y la obtención de recomendaciones claras para la toma de decisiones.

Frente a los nuevos retos que plantea la era de IA, los tomadores de decisiones empresariales sienten la necesidad urgente de herramientas más inteligentes que les ayuden a navegar en un entorno comercial complejo y cambiante. ¿Cómo podemos hacer que la IA no sea sólo un “procesador de datos”, sino un “asesor inteligente” que nos ayude a comprender mejor nuestros problemas y ofrezca soluciones claras y precisas?

En los últimos años, el campo de la inteligencia artificial ha experimentado avances significativos, con modelos de lenguaje de gran tamaño (Large Language Models, LLMs) como GPT-3, GPT-4 y PaLM demostrando capacidades impresionantes de comprensión y generación de lenguaje. Sin embargo, los primeros LLM eran a menudo criticados como “loros estadísticos”, capaces de realizar imitaciones y repeticiones simples, pero careciendo de capacidad real de razonamiento. Por ejemplo, en el artículo “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models” (2201.11903 v 6), los autores señalan que incluso modelos poderosos como GPT-3 muestran una tasa de precisión considerablemente baja ante problemas matemáticos que requieren razonamientos de varios pasos.

Para abordar este problema, los investigadores introdujeron una técnica completamente nueva: Cadena de Pensamiento (Chain-of-Thought, CoT). La técnica CoT puede guiar a los modelos de IA a analizar problemas paso a paso, como lo haría un experto experimentado, proporcionando rutas de razonamiento claras y conclusiones que significan una mejora notable en la capacidad de razonamiento de los LLM y en la precisión de los resultados. La llegada de CoT marca una transición de los LLM de “repetir sin pensar” a “pensar profundamente”, ofreciendo nuevas esperanzas para la toma de decisiones empresariales.

II. La Técnica CoT: El “Mentor Inteligente” en la Toma de Decisiones de IA

Para entender mejor cómo la técnica CoT puede ayudarte a tomar decisiones más informadas, podemos compararla con un “mentor” experimentado. Este mentor cuenta con un amplio conocimiento y experiencia, guiando al modelo de IA a pensar en los problemas como lo haría un experto humano. Cuando planteas un problema complejo a este “Mentor CoT”, no da una respuesta simple de inmediato, sino que guía al modelo de IA a seguir estos pasos:

  1. Descomposición del Problema: Al igual que un profesor experimentado descompone un problema complicado en pasos más simples, el “Mentor CoT” también descompone tu problema en subproblemas más pequeños y fáciles de entender. Por ejemplo, al analizar el potencial del mercado de zapatillas inteligentes, el “Mentor CoT” dividiría el problema en análisis de usuarios objetivo, análisis de competidores y evaluación de riesgos del mercado.

  2. Sugerencias Paso a Paso: Para cada subproblema, el “Mentor CoT” ofrece sugerencias claras y específicas que guían al modelo de IA en su razonamiento. Por ejemplo, al analizar el usuario objetivo, sugeriría considerar la edad, ingresos, profesión, hábitos de consumo y necesidades respecto a las funcionalidades de las zapatillas inteligentes. Estas sugerencias actúan como señales en el camino, guiando el pensamiento del modelo en la dirección correcta.

  3. Razonamiento Lógico: Mientras el modelo de IA analiza cada subproblema, el “Mentor CoT” asegura que el proceso de razonamiento sea lógico y que los pasos estén interconectados, integrando finalmente los resultados del análisis de todos los subproblemas para llegar a una conclusión final que sea clara y coherente. Esto es similar a un científico riguroso que valida cada resultado experimental para garantizar la confiabilidad de las conclusiones.

1
2
3
4
graph LR
A[Descomposición del Problema] --> B[Sugerencias Paso a Paso]
B[Sugerencias Paso a Paso] --> C[Razonamiento Lógico]
C[Razonamiento Lógico] --> D{Conclusión Final}

Este código generará un diagrama de flujo simple que muestra los tres pasos clave de CoT: descomposición del problema, sugerencias paso a paso y razonamiento lógico, llevando finalmente a la conclusión final. Puedes usar este código en plataformas que soportan mermaid, como editores Markdown o herramientas en línea de diagramas.

Aquí hay un diagrama de flujo más detallado que muestra el proceso CoT con más símbolos:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
graph LR
A[Problema Complejo] --> B{Descomposición del Problema}
B{Descomposición del Problema} --> C1[Subproblema 1]
B{Descomposición del Problema} --> C2[Subproblema 2]
B{Descomposición del Problema} --> C3[Subproblema 3]
C1[Subproblema 1] --> D1[Sugerencias Paso a Paso]
C2[Subproblema 2] --> D2[Sugerencias Paso a Paso]
C3[Subproblema 3] --> D3[Sugerencias Paso a Paso]
D1[Sugerencias Paso a Paso] --> E1[Razonamiento Lógico]
D2[Sugerencias Paso a Paso] --> E2[Razonamiento Lógico]
D3[Sugerencias Paso a Paso] --> E3[Razonamiento Lógico]
E1[Razonamiento Lógico] --> F{Integración de Resultados}
E2[Razonamiento Lógico] --> F{Integración de Resultados}
E3[Razonamiento Lógico] --> F{Integración de Resultados}
F{Integración de Resultados} --> G[Conclusión Final]

Este diagrama de flujo ilustra con mayor claridad el flujo de trabajo de CoT: incluyendo la descomposición en subproblemas, cada subproblema sujeto a sugerencias paso a paso y razonamiento lógico, y, finalmente, la integración de todos los resultados para desarrollar una conclusión contundente.

A través de estos tres pasos, el “Mentor CoT” puede ayudar al modelo de IA a llevar a cabo un análisis en profundidad de problemas complejos y a ofrecer caminos de razonamiento claros y conclusiones fundamentadas.

Por ejemplo, al analizar el potencial del mercado de zapatillas inteligentes, la técnica CoT puede guiar al modelo a analizar las siguientes cuestiones:

  • Análisis de Usuarios Objetivo: El modelo analizará datos sobre la edad, ingresos, profesión, estilo de vida, hábitos deportivos, preferencias respecto a la funcionalidad, precio, marca, etc., logrando así una segmentación más precisa del público objetivo.
  • Análisis de Competidores: El modelo evaluará características del producto, estrategias de precios, usuarios objetivo, cuotas de mercado y la fuerza de la marca de los competidores, ayudándote a entender el panorama competitivo y a diseñar estrategias diferenciadas.
  • Evaluación de Riesgos del Mercado: El modelo analizará tendencias de desarrollo del sector de dispositivos portátiles, factores de riesgo como regulaciones, desafíos tecnológicos y la seguridad de la privacidad del usuario, ayudándote a prever riesgos potenciales y a elaborar estrategias de mitigación.

Al final, la técnica CoT integra los resultados del análisis en un informe que es coherente, completo y directo, facilitando así la toma de decisiones informadas y estratégicas.

Diversas investigaciones han demostrado la efectividad de la técnica CoT. Por ejemplo, se ha mostrado que el uso de indicaciones CoT mejora significativamente la precisión de los modelos de lenguaje grande (LLMs) al abordar problemas de razonamiento complejos.

III. Casos de Uso de la Técnica CoT: Empoderando a las Empresas, Creando Valor

La técnica CoT ya ha demostrado su gran valor en diversos campos comerciales, ayudando a las empresas a resolver complejos problemas comerciales, aumentar la eficiencia, reducir costos y mejorar la experiencia del usuario, creando así aporte real a su valor comercial. A continuación, mostraremos cómo la técnica CoT ha empoderado a las empresas, presentando ejemplos concretos.

Caso 1: Análisis de Competencia de Mercado

Contexto del Caso:

Supongamos que eres director de marketing de una nueva empresa de vehículos eléctricos y planeas lanzar al mercado un nuevo SUV eléctrico. Para desarrollar estrategias de mercado efectivas, necesitas entender a fondo el perfil de tu público objetivo, los competidores y las tendencias del mercado que te permitan una segmentación y estrategia de marketing más precisas.

Solución CoT:

Los informes de investigación de mercado tradicionales suelen ofrecer únicamente datos y gráficos, dificultando un análisis profundo y un razonamiento efectivo. Con la técnica CoT, puedes guiar al modelo de IA para que actúe como un experimentado analista de mercado, proporcionando un análisis paso a paso de la situación comercial y ofreciendo una conclusión bien fundamentada.

Ejemplo de Preguntas:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Problema: Analizar el grupo objetivo del nuevo SUV eléctrico, los principales competidores y las tendencias futuras del mercado.

Análisis Paso a Paso:
1. Grupo objetivo:
    * Analizar datos de usuarios potenciales en términos de edad, ingresos, profesión, estilo de vida, presupuesto de compra y sus actitudes hacia los vehículos eléctricos.
    * Evaluar la demanda de funcionalidades en el SUV eléctrico, como autonomía, facilidad de carga, características inteligentes y seguridad.
    * Identificar preferencias hacia marcas y sensibilidad al precio entre los usuarios.

2. Análisis de Competencia:
    * Identificar a los competidores clave, como Tesla, BYD y NIO, así como sus productos destacados y posición en el mercado.
    * Evaluar el rendimiento del producto, estrategias de precios, canales de venta y enfoques de marketing de los competidores, determinando sus fortalezas y debilidades.
    * Analizar las orientaciones tecnológicas y planes de desarrollo futuro de los competidores, como sus inversiones en conducción autónoma, tecnología de baterías, y cabinas inteligentes.

3. Predicción de Tendencias del Mercado:
    * Analizar las tendencias generales en el sector de vehículos eléctricos, incluyendo regulaciones, avances tecnológicos y desarrollo de infraestructura de carga.
    * Predecir cambios en la demanda de los usuarios, por ejemplo, sus expectativas respecto a autonomía, inteligente y seguridad.
    * Evaluar la futura competencia en el mercado, como nuevos entrantes y productos sustitutivos.

Por último, por favor, integra los análisis anteriores y proporciona una evaluación global de las perspectivas del nuevo SUV eléctrico en el mercado.

Valor Comercial:

A través del análisis guiado por CoT, el modelo será capaz de ayudarte a:

  • Definir de forma más precisa el perfil de tu público objetivo, aumentando la efectividad de tus estrategias de marketing y las tasas de conversión.
  • Obtener una comprensión más abarcadora del estado de tus competidores, permitiéndote construir estrategias de productos y precios diferenciadas que mejoren tu competitividad.
  • Evaluar y pronosticar tendencias del mercado con precisión, aprovechando oportunidades y mitigando riesgos potenciales para definir estrategias de desarrollo más sólidas.

Caso 2: Evaluación de Riesgos

Contexto del Caso:

Eres el Director de Riesgos de una empresa de tecnología financiera, encargado de evaluar los riesgos de un nuevo producto de préstamos dirigido a usuarios jóvenes con poco historial crediticio, que utiliza grandes datos y tecnologías de IA para evaluar créditos y fijar peligros.

Solución CoT:

Los modelos tradicionales de evaluación de riesgos que se basan en datos históricos y estadísticas son inapropiados para evaluar de forma precisa el riesgo de nuevos grupos de clientes. La técnica CoT puede ayudarte a construir un modelo de evaluación de riesgos más inteligente, guiando al modelo a analizar los diversos factores de riesgo y ofrecer conclusiones precisas y completas.

Ejemplo de Preguntas:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Problema: Evaluar los riesgos del producto de préstamos dirigido a usuarios con poco historial crediticio.

Análisis Paso a Paso:
1. Análisis del Grupo de Usuarios:
    * Examinar la edad, ingresos, profesión, hábitos de consumo y el historial crediticio de los usuarios objetivo.
    * Evaluar la capacidad y disposición de los usuarios para devolver el préstamo, incluyendo estabilidad de ingresos, nivel de endeudamiento y mentalidad respecto al consumo.
    * Analizar las preferencias en términos de riesgo de los usuarios, por ejemplo, su interés por inversiones con alta potencialidad de retorno.

2. Análisis del Diseño del Producto:
    * Evaluar la lógica y sensatez del monto, plazos, tasas de interés y métodos de reembolso del préstamo.
    * Analizar la precisión y solidez del modelo de evaluación crediticia, considerando las características, algoritmos y datos de entrenamiento utilizados.
    * Investigar las estrategias de gestión de riesgos, como la revisión previa a la concesión, el monitoreo durante el préstamo y la gestión de cobranzas.

3. Análisis del Entorno del Mercado:
    * Examinar como el entorno macroeconómico impacta en el producto de préstamos, incluyendo crecimiento económico, tasas de interés y situación del empleo.
    * Evaluar cómo las regulaciones y políticas afectan el desarrollo del producto de préstamos, incluyendo políticas regulatorias y normas de la industria.
    * Analizar las estrategias de gestión de riesgos de los competidores, como su audiencia objetivo, modelos de evaluación crediticia y estrategias de gestión de riesgos.

Finalmente, por favor, integra los análisis anteriores y proporciona un informe de evaluación de riesgos que incluya recomendaciones de control de riesgos.

Valor Comercial:

Con la técnica CoT, puedes:

  • Construir modelos de evaluación de riesgos más precisos, disminuyendo la tasa de morosidad del producto de préstamos y mejorando la rentabilidad.
  • Optimizar las estrategias de gestión de riesgos, disminuyendo costos operativos y aumentando la eficiencia de la gestión de riesgos.
  • Identificar y gestionar los riesgos de crédito de grupos de nuevos usuarios de forma más efectiva, abriendo nuevos mercados y áreas de negocio.

Caso 3: Toma de Decisiones de Inversión

Contexto del Caso:

Eres socio de una compañía de inversiones y estás considerando invertir en una empresa tecnológica en etapas iniciales. Esta empresa cuenta con tecnologías y productos innovadores, pero también enfrenta serias amenazas competitivas y un modelo de negocio aún en desarrollo.

Solución CoT:

Las decisiones de inversión tradicionales suelen depender de análisis financieros y de mercado que no siempre logran evaluar el potencial de desarrollo a futuro de empresas tecnológicas en etapas tempranas. La técnica CoT puede ayudarte a construir un modelo de decisión de inversión más inteligente, guiando el modelo a analizar competidamente la competitividad de la empresa, sus barreras tecnológicas, ventajas de mercado, capacidades del equipo, etc., proporcionando recomendaciones de inversión más precisas y completas.

Ejemplo de Preguntas:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Problema: Evaluar la viabilidad de invertir en una empresa tecnológica en etapas tempranas.

Análisis Paso a Paso:
1. Análisis del Negocio:
    * ¿Cuál es el núcleo del negocio de la empresa? ¿Qué innovaciones presenta su producto/servicio?
    * Evaluar el público objetivo y el potencial de crecimiento de la demanda del mercado.
    * Valorar su modelo comercial, incluyendo modelos de ingresos, fuentes de ingresos y estructura de costos.

2. Análisis Tecnológico:
    * Estudiar las tecnologías clave de la empresa, incluyendo patentes, ventajas algorítmicas y barreras tecnológicas.
    * Evaluar al equipo tecnológico, sus experiencias, habilidades y capacidades innovadoras.
    * Explorar sus cronogramas de desarrollo tecnológico y planes de inversión en futuras innovaciones.

3. Análisis de Mercado:
    * Examinar las tendencias del sector donde opera la empresa, incluyendo tamaño del mercado, tasa de crecimiento y dinámica competitiva.
    * Evaluar la competitividad, identificando fortalezas y debilidades al compararla con sus competidores.
    * Predecir su futura participación de mercado y potencial de rentabilidad.

4. Análisis del Equipo:
    * Valorar el equipo de gestión de la empresa, consideraciones sobre el fundador, sus experiencias y cohesión del equipo.
    * Examinar la cultura y los valores empresariales, por ejemplo, su atención a la innovación, experiencia de usuario y responsabilidad social.

Finalmente, por favor, integra los resultados de los análisis anteriores y proporciona un informe sobre la viabilidad de invertir en esta empresa junto con recomendaciones.

Valor Comercial:

Con la técnica CoT, puedes:

  • Construir modelos de decisión de inversión más inteligentes, aumentando la tasa de éxito de las inversiones y logrando retornos superiores.
  • Evaluar con mayor precisión el potencial de desarrollo futuro de empresas tecnológicas en etapas iniciales, identificando oportunidades de inversión más valiosas.
  • Reducir el riesgo de decisiones de inversión, evitando errores y pérdidas.

Resumen

Estos casos son sólo la punta del iceberg respecto a cómo la técnica CoT puede ser aplicada en el ámbito comercial. La técnica CoT puede ser utilizada en cualquier contexto que requiera un razonamiento complejo, como el análisis de mercado, evaluación de riesgos, toma de decisiones de inversión, servicio al cliente, desarrollo de productos, entre otros. Es capaz de ayudar a las empresas a aprovechar mejor sus datos y conocimientos, aumentando su eficiencia operativa, optimizando su proceso de toma de decisiones, y creando valor comercial significativo.

IV. Estrategias de Optimización para la Técnica CoT: Perfeccionismo en la Búsqueda de la Excelencia

Aunque la técnica CoT ha demostrado su potente capacidad de razonamiento, el deseo de perfección es un tema eterno en el desarrollo tecnológico. Para mejorar aún más la efectividad de CoT, los investigadores han desarrollado varias estrategias de optimización que permitirán a CoT simular el pensamiento experto humano, haciendo que el proceso de razonamiento del modelo de IA sea más preciso, eficiente y confiable.

1. Autoconcordancia (Self-Consistency): Validación desde Múltiples Perspectivas para Asegurar Conclusiones Confiables

La autoconcordancia funciona como un mecanismo de “diagnóstico experto”. Esta técnica anima al modelo a analizar un problema desde varios ángulos, asegurando que las conclusiones llegadas en cada uno sean consistentes. Si las conclusiones no concuerdan, el modelo ajustará y corregirá su razonamiento hasta que todos los puntos analizados apunten hacia la misma conclusión, minimizando así el riesgo de errores.

Caso: Análisis de Mercado

Supongamos que deseas evaluar el potencial de mercado de un nuevo producto; un enfoque tradicional de CoT podría llevar al modelo a evaluar únicamente aspectos como el tamaño del mercado y las necesidades de los usuarios, ignorando factores relevantes, como la competencia o cambios normativos.

Aplicando la técnica de autoconcordancia, puedes dirigir al modelo a considerar múltiples perspectivas:

  • Necesidades del Usuario: ¿Cuáles son las características demográficas fundamentales de los usuarios objetivo, y qué esperan en términos de producto?
  • Entorno Competitivo: ¿Qué productos similares existen en el mercado? ¿Cuáles son las ventajas y desventajas de los competidores y cuál es su estructura de precios?
  • Tendencias del Mercado: ¿Cómo se proyecta que cambiará el tamaño del mercado en los próximos años? ¿Qué factores emergentes alterarán la configuración actual?
  • Regulaciones: ¿Qué influencias tienen las políticas del gobierno y regulaciones del sector en el desarrollo y comercialización del producto?

El modelo realizaría análisis múltiples y evaluaría de manera holística el potencial de mercado de nuevo producto. El mecanismo de autoconcordancia asegurará que todos estos resultados converjan en la misma dirección; si existen discrepancias, el modelo revisará factores implicados para definir una conclusión fiable.

2. Guía Iterativa (Iterative Bootstrapping): Método Progresivo para Acercarse a Soluciones Óptimas

La guía iterativa funciona como un “entrenador experimentado”, guiando al modelo a realizar sucesivas rondas de “entrenamiento”. Tras cada ronda, el modelo evaluará su rendimiento y se ajustará en base a las debilidades identificadas, logrando así optimizción.

Caso: Evaluación de Riesgos

Supongamos que deseas evaluar el riesgo de un nuevo proyecto de inversión; tradicionalmente, un modelo de CoT podría enfocarse exclusivamente en identificar un número limitado de riesgos significativos, como riesgos de mercado y tecnológicos. Sin embargo, el enfoque de guía iterativa puede ayudarte a abordar una diversidad mayor de riesgos.

En la primera ronda, el modelo evalúa factores primordiales, ofreciendo un primer informe sobre riesgos. Luego, basado en esa evaluación, realizará un segundo análisis centrado en identificar riesgos adicionales, como riesgos normativos, legales u operativos. Este enfoque iterativo se repetirá hasta que se obtenga una evaluación de riesgos completa y precisa.

3. Algoritmo Evolutivo (Evolutionary Algorithm): Simulando la Evolución para Encontrar Soluciones Óptimas

Los algoritmos evolutivos se inspiran en los procesos de evolución de la naturaleza. Generan múltiples variaciones de las indicaciones de CoT y las tratan como “especies”. A través de un sistema que simula selección natural, cruzamiento y mutación, estos algoritmos irán eliminando indicaciones menos adaptativas y optimizando aquellas más efectivas, encontrando así la mejor instrucción de CoT.

Caso: Toma de Decisiones de Inversión

Imagina que necesitas seleccionar la mejor opción de inversión de varias propuestas. Un enfoque antiguo de CoT podría evaluar sólo el retorno de inversión y el riesgo, dejando de lado aspectos importantes como el ciclo de inversión, liquidez de capital y apoyos normativos.

Los algoritmos evolutivos pueden ayudar a construir un modelo de toma de decisiones de inversión más completo. Primero, generan distintas versiones de indicaciones de CoT, cada una reflejando una estrategia de análisis particular (p.e., una se centra en indicadores financieros, otra en el potencial de crecimiento, y otra en el entorno de regulaciones). El modelo valorará las opciones de inversión a partir de estas indicaciones y luego irá refinando las instrucciones hasta seleccionar la estrategia óptima.

Comparativa de Estrategias de Optimización

La tabla abajo resume las ventajas y desventajas, así como los contextos en los que cada estrategia es más aplicable:

EstrategiaVentajasDesventajasContexto Aplicable
AutoconcordanciaConclusiones confiables, minimización de errores de juicioCostos computacionales elevadosResultados altamente precisos requeridos, como en evaluación de riesgos, decisiones de inversión, diagnósticos médicos
Guía IterativaProceso detallado, optimización progresivaPuede ser costoso en términos de tiempo por múltiples iteracionesTareas que requieren validación y ajustes, como diseño de productos, formulación de planes
Algoritmo EvolutivoResultados de optimización efectivosComplejidad algorítmica, dificultad de implementaciónRequiere optimización a largo plazo y previsión, como en pronósticos de mercado, planificación estratégica

Resumen

Las estrategias de optimización de CoT pueden mejorar la capacidad de razonamiento del modelo, haciendo que sea capaz de abordar problemas complejos de manera más precisa, eficiente y confiable. En su aplicación real, puedes elegir la estrategia de optimización adecuada dependiendo de las necesidades específicas de la tarea y los recursos disponibles, permitiendo que la técnica CoT sirva mejor a tu empresa.

V. Preguntas Comunes sobre la Técnica CoT: Anticipando Riesgos, Previniendo Problemas

A pesar de que la técnica CoT ha conferido a los modelos de lenguaje grandes capacidades de razonamiento sin precedentes, es importante prestar atención a ciertos riesgos y desafíos potenciales en su aplicación. A continuación, enumeraremos cinco problemas comunes en el uso de la técnica CoT, ofreciendo soluciones concretas y recomendaciones para optimizar su uso, para que puedas manejar esta poderosa herramienta de manera efectiva y generar verdadero valor en tu empresa.

1. Explicaciones Erróneas: Aparentemente Razonables, Pero en Realidad Absurdas

Descripción del Problema:

A veces, el modelo genera pasos de razonamiento que parecen coherentes, pero las conclusiones que produce son contradictorias o carecen de sustento lógico, lo que se conoce como “explicaciones erróneas”.

Caso:

En un análisis de informes financieros de una empresa, el modelo podría concluir que “la situación financiera de la empresa es sólida”, mientras que sus pasos de razonamiento muestran que la compañía tiene una alta tasa de endeudamiento y presión sobre el flujo de caja. Tal explicación es claramente contradictoria y poco confiable.

Soluciones:

  1. Validaciones desde Múltiples Perspectivas para Asegurar la Concordancia: Al igual que en un diagnóstico de expertos, permitir que el modelo analice desde diferentes ángulos puede ayudar a comprobar que las conclusiones son congruentes. Por ejemplo, en el análisis financiero, podrías pedir que el modelo evalúe la rentabilidad, la capacidad de pago, la operativa y la evolución para asegurar que todos los ángulos apunten en la misma dirección.

  2. Rastrear la Cadena de Razonamiento para Identificar Fallos Lógicos: Si el modelo presenta una explicación errónea, debes examinar meticulosamente su cadena de razonamiento e identificar cualquier fallo lógico o hipótesis incorrectas. En el ejemplo anterior, el modelo puede haber ignorado ciertos indicadores financieros importantes o interpretado de forma errónea varios índices.

  3. Integrar Conocimientos Externos para Potenciar la Capacidad de Juicio del Modelo: Complementar las indicaciones CoT con bases de datos o los conocimientos de expertos puede ayudar al modelo a interpretar correctamente el problema, evitando razonamientos erróneos. Por ejemplo, en el análisis financiero, incluir criterios contables y estándares del sector puede ayudar al modelo a interpretar mejor las métricas financieras.

2. Diseño de Indicaciones Inadecuadas: Soluciones Que Aciertan en Ciertos Detalles y Fallan en la Conclusión

Descripción del Problema:

El diseño de las indicaciones es una parte crítica en la aplicación de la técnica CoT. Si las indicaciones no están bien elaboradas, el modelo no podrá captar correctamente tu intención, resultando en fallos de razonamiento o la incapacidad de generar conclusiones válidas.

Caso:

Si deseas conocer las opiniones de los consumidores sobre un nuevo producto, pero las indicaciones CoT sólo solicitan que el modelo analice las “opiniones positivas”, ignorando las “opiniones negativas”, el resultado será unilateral y no reflejará el verdadero estado del mercado.

Soluciones:

  1. Definir Claramente el Objetivo y Descomponer el Problema: Antes de diseñar las indicaciones CoT, es fundamental clarificar cuál es tu objetivo de análisis y dividir problemas complejos en subproblemas claros y específicos. Por ejemplo, en el análisis de los comentarios de los usuarios, podrías descomponerlo de la siguiente manera: análisis de críticas positivas, análisis de críticas negativas, identificación de puntos de atención de los usuarios, resumen de sugerencias, etc.

  2. Brindar Información Suficiente para Evitar Ambigüedades: Las indicaciones deben ser informativas y redactadas con claridad, evitando términos vagos que puedan generar confusión. Por ejemplo, en el análisis de comentarios de usuarios, proporcionar criterios específicos de evaluación, como funcionalidades del producto, diseño, precios y servicio.

  3. Referenciar Casos Existentes y Aprendiendo de la Experiencia: Puedes revisar otros ejemplos exitosos de aplicaciones de la técnica CoT, y aprender de las indicaciones de diseño implementadas, realizando los ajustes que sean necesarios para tu situación específica.

3. Pasos de Razonamiento Extensos: Brevedad y Precisión Son la Clave

Descripción del Problema:

En ocasiones, los pasos de razonamiento generados por el modelo son excesivamente largos, incluyen información irrelevante, dificultando la comprensión y aplicación de los resultados.

Caso:

Si deseas conocer la rentabilidad de una inversión, pero el modelo genera un extenso informe de decenas de páginas que incluye análisis de mercado, investigaciones del sector y evaluación de riesgos, tornándose difícil encontrar conclusiones clave rápidamente.

Soluciones:

  1. Establecer Objetivos Claros y Limitar Resultados: En el diseño de las indicaciones CoT, es conveniente definir tu objetivo claramente y limitar la extensión de la salida, pidiendo al modelo que resuma conclusiones en una frase o contenga únicamente los pasos de razonamiento esenciales.

  2. Optimizar las Indicaciones para Redirigir el Pensamiento del Modelo: Utiliza lenguaje claro y sencillo para formular las indicaciones CoT, orientando al modelo a generar pasos de razonamiento más concisos. Puedes incluir mandatos como “da directamente la conclusión” o “resume las razones”.

  3. Intervención Humana para Reducir Contenido: Puedes realizar una intervención manual, seleccionando y simplificando los pasos generados por el modelo, eliminando información irrelevante y enfatizando el contenido crucial.

4. Falta de Información Contextual: Un Cocinero No Puede Cocinar Sin Ingredientes

Descripción del Problema:

Si el modelo carece de información contextual suficiente, como datos relevantes, antecedentes o conocimiento del sector, no será capaz de realizar un razonamiento efectivo, lo que provocará desviaciones en los resultados analíticos.

Caso:

Si deseas prever tendencias del mercado para el siguiente año, pero sólo ofreces datos del último año sin antecedentes más amplios ni tendencias del sector, el modelo tendrá dificultades para realizar predicciones precisas.

Soluciones:

  1. Brindar Contexto Suficiente: En las indicaciones CoT, incluye la mayor cantidad posible de información contextual, como datos relevantes, historial, conocimiento del sector y experiencias de expertos para ayudar al modelo a entender el problema mejor.

  2. Integrar Recursos Externos: Puedes mezclar bases de conocimiento con la técnica CoT, como conectar la infraestructura de datos de la empresa y las bases de datos del sector para reforzar la oferta de información.

  3. Utilizar Diálogos Iterativos para Revisar el Contexto: Adopta un enfoque de diálogo en varias rondas para ir añadiendo contexto, guiando al modelo hacia un razonamiento más profundo. Por ejemplo, al realizar predicciones de mercado, primero permite que el modelo analice los datos históricos y luego proporciona gradualmente información sobre tendencias en las industrias y cambios regulatorios, mostrando así un amplio espectro de análisis.

5. Sesgo en el Razonamiento: Detectar Preferencias, Garantizando Equidad en los Resultados

Descripción del Problema:

El modelo podría mostrar sesgo en sus resultados de razonamiento, como mostrar ilegalmente una preferencia por un grupo específico o ser impactado por limitaciones en los datos de entrenamiento, resultando en resultados desiguales o inexactos.

Caso:

Imagina que utilizas un modelo CoT para la selección de CVs, pero, debido a que la representación de ingenieros mujeres fue baja en los datos de entrenamiento, el modelo podría manifestar sesgo contra las postulaciones de mujeres, resultando en una selección injusta.

Soluciones:

  1. Integrar Datos Diversificados para Entrenar al Modelo: Usa datos variados para entrenar el modelo, asegurando que no haya sesgos en los datos subyacentes que influyan de manera desigual en el razonamiento. Por ejemplo, al entrenar modelos de selección, es esencial equilibrar proporciones entre distintos géneros, razas y grupos de edad.

  2. Mejorar el Diseño de Indicaciones para Evitar Inducciones: Satifacer el diseño de instrucciones para que sean justas y equitativas, evitando el uso de términos que puedan llevar a sesgos prejudiciales. Por ejemplo, evita formulaciones como “los hombres son más idóneos para este trabajo” o “las mujeres son más cuidadosas” en las instrucciones.

  3. Verificar y Ajustar Resultados de Razonamiento: Revisa los resultados de razonamiento del modelo, identifica y evalúa posibles sesgos, ajustando según se requiera. Esto puede incluir la revisión de otro modelo o evaluaciones manuales sobre los resultados de selección, asegurándose de lograr equidad en los resultados.

Resumen

Problema ComúnSoluciones
Explicaciones ErróneasValidaciones desde múltiples perspectivas para asegurar concordancia; rastrear cadenas de razonamientos para identificar fallos lógicos; integrar conocimiento externo para aumentar el juicio del modelo.
Diseño de Indicaciones InadecuadasClarificar objetivos y descomponer el problema; ofrecer información suficiente y evitar ambigüedad; aprender de ejemplos exitosos.
Pasos de Razonamiento ExtensosEstablecer objetivos claros y limitar salidas; optimizar indicaciones para dirigir el pensamiento del modelo; intervenir manualmente para reducir contenido.
Falta de Información ContextualProporcionar contexto suficiente; integrar recursos externos; utilizar diálogos iterativos para construir el contexto.
Sesgo en el RazonamientoUsar datos variados en el entrenamiento del modelo; mejorar el diseño de indicaciones para evitar inducir sesgos; validar y ajustar resultados de razonamiento.

Comprender y abordar estos problemas puede ayudarte a aplicar la técnica CoT más efectivamente, haciendo que los modelos de lenguaje grandes sean asistentes “inteligentes” confiables para la prosperidad de tu empresa.

VI. La Técnica CoT en la Información Empresarial: Fusión Inteligente Para Impulsar la Transformación

La técnica CoT no solo es un tema destacado en la investigación académica, sino que también tiene un enorme potencial comercial. Puede integrarse en los sistemas de información empresarial existentes, inyectando una poderosa dinámica en la transformación digital de la empresa.

1. La Técnica CoT Potencia los Sistemas de Información Empresarial

CoT puede conectarse a diferentes sistemas de información empresarial, liberando el potencial de los datos, mejorando la inteligencia del sistema y creando un mayor valor para la empresa.

  • Sistema de Planificación de Recursos Empresariales (ERP): Los tradicionales sistemas ERP se utilizan principalmente para registrar y gestionar datos de diversas áreas de la empresa, como finanzas, inventario, producción y ventas. Integrando CoT, los sistemas ERP pueden lograr un análisis de datos y predicción más inteligentes. Por ejemplo, CoT podría analizar datos de ventas para identificar tendencias de productos y anticipar ventas futuras, facilitando así una mejor gestión de inventarios y planificación de producción.

  • Gestión de Relaciones con Clientes (CRM): Este sistema se encarga de gestionar las interacciones entre la empresa y sus clientes, como la información de clientes, registros de comunicación o solicitudes de servicio. Con la técnica CoT, el sistema CRM puede lograr percepciones más precisas de los clientes y proporcionar servicios personalizados. CoT podría analizar el historial de compras, registros de navegación y contenido de consultas de los clientes, prediciendo sus necesidades y ofreciendo recomendaciones de productos y servicios personalizados, mejorando así la satisfacción del cliente.

  • Sistema de Inteligencia Empresarial (BI): Este sistema se basa en analizar los datos de la empresa para generar informes y gráficos visuales que ayuden a los managers a entender el estado del negocio y calcular decisiones. CoT puede potenciar la capacidad analítica de BI, identificando automáticamente tendencias en los datos, explicando anomalías y pronosticando desarrollos futuros, ayudando a los directivos a contemplar patrones en los datos para tomar decisiones más informadas.

  • Sistema de Gestión del Conocimiento: Ayuda a almacenar, gestionar y compartir los activos del conocimiento de una empresa, como documentos, casos y experiencias. CoT puede alimentar a un sistema inteligente de gestión del conocimiento, extrayendo automáticamente información clave de documentos, creando gráficos de conocimiento, respondiendo las preguntas de los empleados y promoviendo la compartición y aplicación del conocimiento.

2. La Técnica CoT Facilita la Transformación Digital de las Empresas

La técnica CoT puede impulsar múltiples aspectos de la transformación digital empresarial, ayudando a las empresas a optimizar costos y aumentar eficiencia, mejorando su competitividad.

  • Automatización de Procesos Comerciales: CoT puede automatizar ciertos procesos comerciales que exigen razonamiento complejo, como la revisión de contratos, evaluación de riesgos o análisis financiero, incrementando así la eficiencia, reduciendo costos y liberando recursos humanos para capitalizarlos en tareas más creativas.

  • Aumentar el Nivel de Inteligencia en la Toma de Decisiones: CoT puede ayudar a los directivos a extraer información valiosa de grandes volúmenes de datos y generar pasos de razonamiento fácilmente comprensibles, mejorando así la precisión y eficiencia de las decisiones, minimizando riesgos.

  • Crear Nuevos Productos y Servicios: CoT puede ser útil en el desarrollo de productos y servicios más innovadores, como asistentes virtuales, asesores de inversión, o asistentes legales, ofreciendo a los clientes un servicio más accesible e inteligente y abriendo nuevas oportunidades de mercado y fuentes de ingresos.

Resumen

La técnica CoT se entrelaza de manera inseparable con la construcción de sistemas de información empresarial y transformación digital. Puede fusionarse con los sistemas de información existentes, elevando su valor por su potencial para proporcionar nuevas oportunidades de desarrollo. Creemos que en un futuro cercano, CoT se convertirá en un “motor inteligente” indispensable para las empresas, impulsando la innovación y encaminándolas hacia un futuro cada vez más inteligente.

VII. Perspectivas Futuras de la Técnica CoT: Explorando lo Desconocido, Liderando el Futuro

La técnica CoT, como una tecnología revolucionaria, está liderando una nueva ola en el campo de la inteligencia artificial. Proporciona a los modelos de lenguaje grandes capacidades de razonamiento sin precedentes y abre nuevas vías para resolver problemas complejos.

1. Ventajas y Valor de la Técnica CoT

Las ventajas de la técnica CoT son:

  • Mejora de la Capacidad de Razonamiento: CoT prompting puede guiar a los modelos de lenguaje grandes hacia un razonamiento más profundo, mejorando notablemente su desempeño ante problemas complejos.
  • Mayor Explicabilidad: El proceso de razonamiento en CoT es transparente y comprensible, permitiendo que las personas se hagan una idea de cómo se genera una conclusión, ayudando a construir confianza en los sistemas de IA.
  • Ampliación de Campos de Aplicación: La técnica CoT puede ser aplicada en diversos contextos que requieren razonamientos por pasos, como razonamientos matemáticos, lógicos, de sentido común, análisis de sentimientos, generación de código, etc.

El valor de la técnica CoT radica en:

  • Incrementar la Eficiencia: CoT puede automatizar procesos comerciales que requieren razonamientos complejos, como la revisión de contratos, evaluación de riesgos o análisis financiero, potenciando eficiencia y reduciendo costos.
  • Optimizar la Toma de Decisiones: CoT ayuda a extraer información valiosa de un vasto mar de datos, generando pasos de razonamiento comprensibles que aumentan la precisión y eficiencia de las decisiones.
  • Crear Valor: CoT puede utilizarse para desarrollar productos y servicios innovadores, como asistentes de servicio al cliente, asesores de inversión, y asistentes legales, generando nuevos mercados y fuentes de ingresos.

2. Retos Enfrentados por la Técnica CoT

A pesar de los logros de la técnica CoT, aún se enfrenta a varios desafíos:

  • Explicabilidad y Transparencia: Los métodos actuales de CoT requieren mejoras en las dimensiones de explicabilidad y transparencia de los procesos de razonamiento. Se necesitan herramientas más potentes para comprender mejor estos procesos y asegurar que sean confiables y controlables.
  • Capacidad de Generalización: Los enfoques actuales de prompting de CoT generalmente se diseñan para tareas específicas, lo que limita su capacidad de transferir ese conocimiento. La investigación futura debe explorar métodos de prompting de CoT que sean más universales y aplicables a una mayor variedad de contextos.
  • Robustez: CoT prompting es susceptible a la contaminación de información irrelevante en la entrada, lo que puede llevar a razonamientos erróneos o absurdos. Futuras investigaciones deben buscar métodos de prompting de CoT más robustos que puedan resistir ruido y generar resultados más consistentes.

3. Perspectivas Futuras para la Técnica CoT

El futuro de la técnica CoT brilla con oportunidades, con las siguientes tendencias clave en desarrollo:

  • Fusión con Grafos de Conocimiento: Integrando la tecnología CoT con grafos de conocimiento, pueden ofrecer datos de fondo más ricos al modelo, aumentando tanto su capacidad de razonamiento como su habilidad de generalizar. Por ejemplo, en un análisis de mercado, conectar las indicaciones de CoT con un grafo de conocimiento de la industria puede ayudar al modelo a detectar patrones de tendencia del mercado y contexto competitivo más rigurosos.
  • Integración con Aprendizaje Automático: CoT podrá integrarse con otros enfoques del aprendizaje automático, como el aprendizaje por refuerzo o el aprendizaje meta, para potenciar aún más la capacidad de razonamiento y aprendizaje del modelo. Por ejemplo, estrategias de aprendizaje por refuerzo podrán aprovechar la ruta de razonamientos generados por CoT.
  • Aplicaciones en Escenarios Comerciales Más Complejos: Con el desarrollo continuo de CoT, se aplicará en contextos más dinámicos y desafiantes, como la planificación estratégica, predicción de riesgos y marketing. CoT podrá ayudar a las empresas a crear estrategias de marketing más efectivas, anticipar tendencias del mercado y ajustar planes de marketing conforme cambien las condiciones del mercado.

Resumen

La técnica CoT abre nuevas puertas para las aplicaciones de modelos de lenguaje grandes y promueve un rápido progresso en el desarrollo de la inteligencia artificial en diversas áreas generando oportunidades y valor sin precedente para las empresas. A medida que la tecnología siga progresando y las aplicaciones continúen expandiéndose, la técnica CoT desempeñará un papel cada vez más importante, convirtiéndose en un motor esencial para la digitalización y actualización inteligente en el desarrollo empresarial.

VIII. Conclusión: Abrazando la CoT, Iniciando una Nueva Era de Toma de Decisiones Inteligente

La aparición de la técnica CoT proporciona a las empresas un impulso hacia la inteligencia en sus decisiones. No solo otorga a las máquinas la capacidad de razonar como seres humanos, sino que transformará profundamente las formas de operar y de tomar decisiones en las empresas.

1. Abrazar la CoT para Liberar Potencial Empresarial

Animamos a los altos ejecutivos de las empresas a adoptar activamente la técnica CoT, integrando esta poderosa herramienta en el desarrollo de la información empresarial y la transformación digital. CoT puede ayudar a las empresas a:

  • Descubrir el Valor de los Datos y Descubrir la Esencia Comercial: A través de la guía de la IA en un razonamiento profundo, CoT permite a las empresas extraer información relevante de grandes volúmenes de datos y revelar patrones, sirviendo como un fundamento más firme para la toma de decisiones.
  • Optimizar Procesos Comerciales y Mejorar la Eficiencia: CoT puede automatizar tareas que exigen razonamientos complejos, como la revisión de contratos y evaluación de riesgos, liberando recursos humanos y mejorando la eficiencia operativa reduciendo los costos operativos.
  • Fortalecer la Capacidad Decisional y Aprovechar Oportunidades del Mercado: CoT asiste a los directivos a profundizar el análisis de problemas, prever tendencias, y formular estrategias efectivas, mejorando la precisión y eficiencia de las decisiones, asegurando que la empresa pueda aprovechar oportunidades en el mercado y potenciar su competitividad.

2. Perspectiva Futura: CoT Guiando la Nueva Era de Decisiones Inteligentes

El desarrollo de la técnica CoT está repleta de posibilidades sin límites. A medida que avancen las tecnologías, la CoT se integrará profundamente con otras innovaciones, como los grafos de conocimiento y el aprendizaje automático, aplicándose en contextos de negocios más complejos y desafiantes, tales como planificación estratégica, optimización de marketing, y evaluación de riesgos. CoT se erigirá como una fuerza motriz detrás del desarrollo de la inteligencia empresarial y del cambio hacia la smartificación.

Actúa Ahora y Da Inicio a esta Nueva Era de Decisiones Inteligentes

No esperes más, actúa ahora, adopte la técnica CoT y conviértela en el propulsor que eleve a tu empresa hacia nuevos horizontes, iniciando un camino hacia decisiones inteligentes que conducen a un futuro lleno de éxito.

]]> <h1 id="Introduccion"><a href="#Introduccion" class="headerlink" title="Introducción"></a>Introducción</h1><ul> <li>Se dice que no saber red 【规范驱动】Spec-Driven Development——写规范是 AI 时代 ROI 最高的工程动作 AI 时代软件工程变革——慢慢学AI177 https://iaiuse.com/posts/%E8%A7%84%E8%8C%83%E9%A9%B1%E5%8A%A8-spec-driven-development-%E5%86%99%E8%A7%84%E8%8C%83%E6%98%AF-ai-%E6%97%B6%E4%BB%A3-roi-%E6%9C%80%E9%AB%98%E5%B7%A5%E7%A8%8B%E5%8A%A8%E4%BD%9C-ai-%E6%97%B6%E4%BB%A3%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B%E5%8F%98%E9%9D%A9 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z

文中数据来源：CodeRabbit 2025.12 / New Relic 2026 报告、Microsoft Work Trend Index 2026、Microsoft FY26 Frontier Firms 公告、GitHub Spec Kit、AWS Kiro、OpenAI Codex、Claude Code、Alibaba Qoder、JetBrains 2026.1 AI Pulse。案例为代表性场景归纳，不指向具体企业。

你最大的错误不是没买工具，是没写 CLAUDE.md

一家股份制银行的 CIO 跟我抱怨：AI 工具买了、模型部署了、人也训了，2026 H1 整半年下来交付周期几乎没动。核心系统组的负责人更直接：”AI 写的代码能用，但每次都要重写一遍——它不懂我们行的规则、不懂监管要求、不懂怎么和那个 30 年历史的老系统对接。”

问题不在 AI 不够强，在于你们没把规则写下来。CodeRabbit 在 2025 年 12 月对 470 个开源 PR 的分析给出了一组被广泛引用的数字：AI 协作 PR 平均含 10.83 个问题，纯人工 PR 6.45 个——1.7 倍，比人工多 70% 的 bug。到 2026 年，故事没有反转：New Relic 在《2026 State of AI Coding Report》里发现，78% 的团队在 AI 代码上线后报告了更多事故，62% 的技术领导者承认他们的团队”自信地不逐行审查就直接发” AI 代码（New Relic 官方报告 2026，0.866 score，一级源）。两组数据说的是同一件事——AI 不缺能力，缺上下文。

2026 年 8 月这个时点，所有”AI 转型加速”的叙事都得放在一组对照里看：

阵营进展（2026 H1）反例（2026 H1）
EYMicrosoft 365 Copilot 铺到 150,000 员工，节省 250 万小时 / 2.5 亿美元；扩展到 40 万全球员工同时承认 95% 提速、37% 财务运营成本下降的前提是”规范先行”
Atos部署到 54 国 / 56,000 员工；同时跑 19,000 个 AI 代理，统一身份/安全/合规/治理控制平面严守”先把 Agent 365 的治理能力上线、再扩规模”
Microsoft 自身2026 Work Trend Index：82% 领导者计划 12-18 个月内用 AI 代理扩展劳动力同期承认”组织变革的节奏落后于个人使用”——这是 Frontier Firm 概念里的核心矛盾

来源：Microsoft FY26 retrospective 2026.7.28；Microsoft 2026 Work Trend Index Annual Report 2026.5.5；New Relic 2026 State of AI Coding Report。

这两组对照说明一件事：没有规范，规模化等于把风险乘以 N。EY/Atos/Microsoft 的”快”不是模型快，是”组织先答完怎么用 AI 的问题”。这是 Spec-Driven Development（SDD，规范驱动开发）在 2026 H1 真正主流化的背景——不是因为工程师偏好文档，是因为不写规范已经无法在 19,000 个代理的环境里活下来。

这篇文章讲清三件事：1）AI 代码的缺陷为什么比人工严重到 1.7 倍以上；2）GitHub、AWS、OpenAI、Anthropic、Alibaba 五家平台在 2026 H1 怎么走向同一个范式——用文档约束 AI 行为；3）规范驱动为什么是组织能力、不是工具选择，以及 2026 H1 的落地三阶段。

AI 代码 vs 人工代码：缺陷分布（470 个开源 PR 分析） CodeRabbit 2025.12 报告｜所有数字为 AI / 人工的倍数比（基准线 1.0）

条形长度 = AI 缺陷是人工的倍数；基准线 1.0× = 人工水平

基准 1.0×

总体问题数

1.7×
AI 10.83 vs 人工 6.45 / PR

逻辑 / 正确性错误

1.75×

代码质量 / 可维护性

1.64×

安全发现（综合）

1.57×

密码处理不当

1.88×

XSS 漏洞

2.74×
↑ 最高

没有规范约束的 AI 代码，每个维度都高于人工
金融/电信 = 合规对账、密码管理、敏感字段加密，AI 全都看不到

一、AI 缺陷率不是模型问题，是上下文问题

CodeRabbit 报告里有一句话被反复引用过：**”AI 缺乏本地业务逻辑：模型按统计推断代码模式，而非语义理解。没有严格约束，它们会错过资深工程师内化的系统规则。”**

这句话解释了为什么 CodeRabbit 自己的 AI 编程平台（一个专门做 AI 代码审查的公司）会比别人更早看到这组数据——他们每天看几千个 PR，每天看 AI 写出来的代码长什么样。”最关键”的发现不是总数，是分布：

  • **逻辑/正确性 +75%**：业务逻辑错误、依赖关系错误、控制流错误、配置错误——这类问题在测试里不一定暴露，但会在生产环境导致事故。
  • **代码质量 +64%**：命名不一致、结构不清晰、违反项目模式——这是”最大差异类别”。资深工程师一眼就看出来”这不是我们这儿的写法”。
  • 安全 +57%（XSS 类最高 2.74×）：密码处理不当（1.88×）、不安全的对象引用（1.91×）、敏感信息泄露、不安全反序列化（1.82×）——**在金融行业，这不是”能不能用”，是”能不能发”**。

问题不在 AI 不够强。在于它看不到。

回到那位 CIO 的真实卡点，AI 在金融核心系统的三个具体故障：

第一，AI 看不到 30 年的对账逻辑。 银行的风控规则写在核心系统的存储过程里——30 年前写的，没人记得全。AI 生成的代码逻辑看起来没问题，但在生产环境会触发那条没人记得的对账检查，导致整批交易失败。

第二，AI 看不到合规约束。 密码必须走密钥管理系统、敏感字段必须加密存储、日志不能打印客户信息——这是监管硬约束，写在内部制度里。AI 不知道，写出来的代码能跑但过不了合规审查。

第三，AI 看不到你的技术债。 那个 30 年的宿主系统用的是一套自己的接口协议，文档早就丢了。AI 按通用 RESTful 规范写代码，上线后发现接口对不上——返工两周。

回到 New Relic 的另一组数字：62% 的团队”自信地不审查就发” AI 代码，78% 在上线后报告了更多事故。这两个数字拼在一起，等于在说——AI 代码的缺陷率本身不是问题，”我不知道 AI 代码有什么缺陷”才是问题。

典型场景：某股份制银行引入 AI 辅助开发核心系统的风控模块，三个月内合规审查退回率显著上升，主要问题是密码管理、敏感字段加密、日志合规等内部规则。这些规则都写在内部文档里，但 AI 看不到。后来团队把核心规则写成 CLAUDE.md，退回率明显下降。

二、五大平台的 2026 H1：殊途同归的”规范驱动”

2025 年 7 月 GitHub 发布 Spec Kit，2026 年初 AWS Kiro、OpenAI Codex、Anthropic Claude Code 全部补齐；2026 年 5 月 Alibaba Qoder 把”Spec-Driven Workflow”写进了产品定位。五大平台在 2026 H1 走到了同一个范式——用文档约束 AI 行为。这不是哪一家公司的发明，是行业对”AI 代码质量危机”的集体回应。

五大平台的规范驱动路径（2025-2026 H1） GitHub Spec Kit 开源 2025.9 constitution.md 五阶段门控： constitution → specify → plan → tasks → implement 模型无关，可接 8+ 代理 Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md 三阶段工作流： 需求 → 设计 → 任务 spec-driven 写进 IDE 工作流 钩子触发自动代理 合规/审计钩子预埋 不写 spec 就启动不了 OpenAI Codex 2025-2026 AGENTS.md + Skills 系统 可组合指令集 团队级共享配置 5M+ 周活（2026.6） 非开发者占 20% 从编程走向通用代理 Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + Skills（官方市场 2026.2） + MCP 生态 CSAT 91% / NPS 54 $2.5B ARR（2026.2） GitHub 11.2 万 stars Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Quest Mode 自主执行 + Expert Mode 团队 + RepoWiki 上下文 5M+ 全球用户（2026.5） 2026.7.21 Qoder Security 钉钉 CLI 已接入 共同范式：把"我们怎么和 AI 协作"显式写成文档，放在仓库里 让所有人和所有 AI 代理都对着同一份规范工作——这是规范驱动的本质

逐个看每个平台在 2026 H1 的最新动作：

GitHub Spec Kit：参考实现，五阶段门控。 2025 年 9 月开源，到 2026 H1 已经成为行业参考实现。5 个核心命令 + 2 个补充：/speckit.constitution（不可协商原则）、/speckit.specify（要做什么、为什么）、/speckit.plan（怎么改）、/speckit.tasks（拆任务）、/speckit.implement（执行），加上 /clarify 和 /analyze。它的关键设计是模型无关——同一份 spec/plan/tasks 文件不绑定执行代理，Claude Code、Copilot、Cursor、Codex CLI、Gemini CLI、opencode、Windsurf、Qwen Code 都能接。这让它变成了”组织级 SDD 协议”，而不是 GitHub 专属产品（vibecoding.app 评测 2026.6，0.816 score，二级源）。

AWS Kiro：把规范驱动刻进 IDE。 2025 年 7 月发布，2026 H1 演进为完整的 Agent IDE。三阶段工作流：需求 → 设计 → 任务。和 Spec Kit 区别在”钩子”——Kiro 的 spec 文件能触发预定义的代理动作，把合规/审计/部署这类需要外部系统的步骤预埋进工作流。想强制团队写规范，就选 Kiro——因为你不写 spec，Kiro 启动不了（AWS Kiro 官方 2025.7；Kiro.dev 文档 2026）。

OpenAI Codex：AGENTS.md + 可组合 Skills。 2025-2026 把 AGENTS.md 推到生态中央。Skills 是 2026 H1 的关键扩展：把”读 Excel 表””生成 SQL””跑数据迁移”这些工序预拼好，像乐高一样调用。Codex 周活在 2026 年 6 月已破 500 万，其中 20% 是非开发者——这是个被忽略的信号：规范驱动已经不只是工程团队的事，是全员的事，产品、运营、风控都在写 AGENTS.md（OpenAI 2026.6.2 公告；thebcms.com 评测 2026，0.801 score）。

Claude Code：CLAUDE.md + .claude/rules/ + Skills。 Anthropic 把项目指令文档叫 CLAUDE.md（2026 年 2 月进官方市场）、.claude/rules/（按目录分层的规则）、Skills（可共享的工作流）。Claude Code 是 2026 H1 开发者满意度最高的工具——JetBrains 2026.1 调研给的数字是 CSAT 91%、NPS 54，两个独立调研（Pragmatic Engineer 2026.2）一致。这是行业目前 AI 编程工具赛道的最高分（uvik.net 2026.5，0.956 score，一级源汇总）。Claude Code 在 9 个月内从 0 冲到 25 亿美元年化营收（2026.2 Anthropic G 轮口径），GitHub 11.2 万 stars（Skills 仓库）——开发者用脚投票说明了规范驱动的真实价值。

Alibaba Qoder：中国市场的规范驱动。 2025 年 8 月发布，2026 年 5 月 15 日升级到 1.0 版本，正式从”AI IDE”升级为”Autonomous Agent Development Workbench”。它的 Spec-Driven Workflow 是和 Quest Mode（自主多文件任务）、Expert Mode（专家团队并行）、RepoWiki（仓库知识图谱）一起推出的。2026 年 5 月 28 日上线 Cloud Agents（完全托管的代理运行时），7 月 21 日上线 Qoder Security（合规安全能力），同月推出 Mobile 版（Android/iOS/鸿蒙）。到 2026 年 5 月全球用户已超 500 万，钉钉 CLI 把它列为支持的代理执行环境之一（Yahoo Finance 2025；Alibaba Cloud 官方 2026；Baidu Baike 2026.7）。

共同范式：把”我们怎么和 AI 协作”显式写成文档，放在仓库里，让所有人和所有 AI 代理都对着同一份规范工作。 五家平台的实现细节不同（文件名/阶段数/钩子机制），但目标完全一致。

为什么这件事 2026 H1 集中发生？因为 AI 能力门槛已经过去了——Claude Code 自主代理、Codex 多代理并行、Cursor 多文件重构，AI 不再是”补全工具”，是”同事”。你能给新同事的入职文档，必须也能给 AI 看。

三、规范驱动是组织能力，不是工具选择

这是对决策者最重要的一条。规范驱动不是选工具，是定义”我们组织怎么和 AI 协作”。 你选 GitHub Spec Kit 还是 Claude Code 不重要，重要的是你有没有把规范写成文档、放进仓库、让所有人和 AI 都对着它工作。

没有这个，再好的工具也只是让团队用更快的速度造更多的债。

把这件事放到 2026 H1 的规模化部署里看，证据更硬。Microsoft 在 2026 年 7 月的 FY26 retrospective 里，把 EY 和 Atos 两个案例写成”Frontier Firm”模板——不是因为模型新，是因为这两家都先答完”怎么用 AI”的问题：

EY：规范先行，规模化兑现。 EY 在 2024-2025 把 Microsoft 365 Copilot 铺到 15 万人，节省 250 万小时、约 2.5 亿美元。**前提是”AI 治理框架先建好”：EY 用 Power Platform、Copilot Studio、Azure、Foundry、Fabric 做了统一的工具链，把规范/合规/审计放进同一个底座。这才有后面的 95% 提速、37% 财务运营成本下降、最高 90% 的手工工作流减少。EY 的副总裁在 2026 AI Tour 上讲得很直接：“我们不是先铺 AI 再补治理，是先补治理再铺 AI”**。

Atos：19,000 个代理的统一控制平面。 Atos 是全球第一批部署 Microsoft 365 E7（Frontier Suite）的组织，把 Copilot 铺到 54 国 56,000 名员工。同时在跑 19,000 个 AI 代理——从内部 IT、业务部门到客户项目，全在用 Foundry + Copilot Studio 建代理。Atos 把这件事做成的关键是”一个控制平面”：Entra（身份）+ Defender（安全）+ Intune（设备）+ Purview（合规）+ Agent 365（代理治理），五件事绑定在一起。这种绑定方式，对应到金融行业就是”等保 + 数据出境 + 算法备案 + 审计 + 模型治理”，是治理架构而不是单纯的 AI 工具。

Microsoft 自己的”组织变革悖论”。 2026 Work Trend Index 报告里，Microsoft 自己承认了一件事：**”组织变革的节奏落后于个人使用”。他们调研的 20,000 名 AI 使用者里，82% 领导者计划在 12-18 个月内用 AI 代理扩展劳动力，但只有 24% 已经在企业级部署完成。81% 领导者预计 AI 代理会被中等或大量地集成进 AI 战略——但同样只有 24% 已经做到。这意味着绝大多数企业在”准备”和”做到”之间还有 12-18 个月的距离，这段距离怎么填，规范驱动是主要承重点**。

来源：Microsoft FY26 retrospective 2026.7.28；Microsoft 2026 Work Trend Index Annual Report 2026.5.5（assets-c4akfrf5b4d3f4b7.z01.azurefd.net，PDF 一级源）；Futurum Group 2026.1.26 分析（二级源）。

启示一：投资规范是高 ROI。

CodeRabbit 的数据给出了明确的 ROI 计算基础：AI 代码问题率约 1.7 倍、安全漏洞减少 2.74 倍。这意味着：

  • 更少的返工（金融行业一个合规审查返工就是 2-4 周）
  • 更少的安全事故（一个数据泄漏事件的监管罚款、声誉损失）
  • 更低的维护成本（技术债减少 40% 是常见数字）

写一份 CLAUDE.md/AGENTS.md 项目规范，是 AI 时代 ROI 最高的工程动作。EY 的案例给了真实世界的换算——15 万人铺 Copilot，节省 2.5 亿美元。注意 EY 不是因为”工具厉害”省下的，是因为”规范把工具的价值兑现了出来”。

启示二：把规范写进组织流程，而不是依赖个人。

规范如果只存在某个资深工程师的脑子里，人员一流动就丢了。必须沉淀到：

  • 仓库文档（AGENTS.md / CLAUDE.md / constitution.md）
  • CI 门控（自动检查规范遵守情况）
  • 团队共享配置（Skills 系统让全团队能用）

让规范成为组织资产，不是个人技能。这在金融行业尤其重要——你们的合规要求、安全规则、业务规则都是组织级资产，不是某个工程师的”经验”。Atos 的 19,000 个代理能在 54 国跑，因为治理不是”某个人懂”，是”系统强制”。

启示三：门控比速度重要。

GitHub Spec Kit 的五阶段门控（constitution → specify → plan → tasks → implement）、Claude Code 的”测试失败前不写代码”、Kiro 的”不写 spec 启动不了”，都在做同一件事：在 AI 和最终产出之间加”刹车”。每一步都有可审查的产物（spec.md、plan.md、tasks.md），都可以在代码生成前被否决或修改。

自主性越强的 AI，越需要门控。 金融行业的变更审批委员会（CAB）、算法备案流程、等保测评，本质上都是在生产之前加门控。AI 代码也需要类似的门控，只是形式不同。新 Relic 2026 报告里那 62% “自信地不审查就发”的团队，正在用更高的事故率（78%）为这种自信买单。

金融行业规范落地三阶段（2026 H1 实操版） 第一阶段：盘点规则 2-4 周｜最花时间，ROI 最高 合规要求清单（等保/出境/备案） 安全规则（密码/加密/日志） 业务规则（风控/交易/计费） 技术约束（老接口/版本限制） 供应商治理（合同/审计/责任） 把散落在各处的规则 整理成结构化文档 第二阶段：落进仓库 1-2 周｜放进仓库，AI 自动加载 CLAUDE.md / AGENTS.md constitution.md Skills 定义（可共享工作流） 门控流程设计（五阶段） .claude/rules/（分层规则） 把规则放进仓库， AI 自动加载 第三阶段：制度化 持续｜从工具变组织能力 CI 门控（自动审查） 团队共享配置（Skills） 定期更新机制（季度评审） 度量（缺陷率/合规通过率） 代理治理（Agent 365 一级） 规范成为组织资产， 不依赖个人

第一阶段最花时间，但 ROI 最高
大部分金融组织的规则都散落在文档/邮件/人脑里，第一次整理是 3-8 周的投入

四、2026 H1 的真实落地三阶段

以金融行业为例的三阶段路径，其他强监管行业可参考。EY 和 Atos 2026 H1 的实践刚好对应这三个阶段。

第一阶段：盘点规则（2-4 周）。

这是最花时间但 ROI 最高的阶段。把散落在各处的规则找出来：

  • 合规要求：金融业最低基线 = 等保三级 + 数据出境评估 + 算法备案（缺一项就别铺 AI），往上还有监管报送规则、客户信息保护、跨境数据流转限制、哪些数据可以给 AI 看
  • 安全规则：密码管理、加密标准、敏感字段处理、日志要求
  • 业务规则：风控阈值、理赔条件、交易限制、计费逻辑
  • 技术约束：老系统接口、数据库命名、框架版本限制
  • 供应商治理：怎么在合同里要求供应商用我们的规范、怎么审计供应商的 AI 使用

典型场景：某证券公司在盘点阶段发现，规则散落在大量 Word 文档、JIRA wiki、个人邮件、Excel 表格里——整理后才得到结构化的规则清单。Atos 的做法更系统——他们直接把规则按”合规、安全、业务、技术、供应商”五类拆开，每类一个治理工作流，统一接入 Agent 365 的控制平面。

这不是技术活，是组织活——你得把合规部门、安全部门、业务部门拉到一起，把大家都认可的规则写下来。第一次做这个，金融组织通常要 3-8 周——但这是永久性的组织资产。

第二阶段：落进仓库（1-2 周）。

把第一阶段整理的规则写成文档、放进仓库。GitHub Spec Kit 用 constitution.md，Claude Code 用 CLAUDE.md，OpenAI Codex 用 AGENTS.md，Alibaba Qoder 用 Spec Workflow。文件名不同，目标一致——让 AI 在打开仓库那一刻就加载。

结构建议（2026 H1 主流形态）：

  • 项目概述：这个系统是干什么的，服务谁
  • 不可协商原则：安全红线、合规红线、业务红线
  • 技术栈和约束：用什么框架、什么数据库、什么接口规范
  • 代码规范：命名约定、目录结构、测试最低覆盖要求（不强制 TDD 节奏——把测试覆盖率、必测路径、禁区路径写清即可，TDD 是组织可选节奏，不是规范驱动的硬要求）
  • 业务规则：风控逻辑、交易规则、计费规则
  • 合规要求：等保、数据出境、监管报送、AI 生成算法是否需要备案
  • AI 使用规范：什么场景可以用 AI、什么场景必须人工审查、数据出境规则
  • 供应商治理：合同条款、审计机制、责任划分

附录：CLAUDE.md 金融版骨架（约 200 行，可直接 fork 改造）

下面是一份针对股份制银行核心系统改造的 CLAUDE.md 骨架，已按”不可协商原则 → 合规要求 → AI 使用规范 → 业务规则 → 工程约束”的顺序组织。你公司不需要从零开始——把空槽填进你们的具体规则就行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
# CLAUDE.md — <系统名> AI 协作规范

> 适用范围：<系统名> v<版本>，所有 AI 代理（Claude Code / Cursor / Copilot / Codex）
> 在本仓库工作时必须遵守本规范。本文件由 <治理委员会> 维护，季度评审。
> 最后更新：YYYY-MM-DD

## 1. 项目概述
- **业务定位**：核心系统名 / 服务客群 / 主要交易类型
- **关键链路**：交易 → 风控 → 清算 → 对账 → 报送
- **不可用窗口**：<YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM>（任何变更禁止进入）
- **核心依赖**：上游 <系统>、下游 <系统>、监管报送平台

## 2. 不可协商原则（红线，违反即拒绝合并）

### 2.1 安全红线
- 密码、密钥、Token 一律走 KMS（密钥管理服务），**禁止硬编码**、**禁止日志打印**
- 客户敏感字段（身份证 / 卡号 / CVV / 手机号）**必须加密存储**，明文禁止落库
- 日志中禁止出现：完整身份证、完整卡号、明文密码、客户姓名+手机号组合
- 外部接口调用必须经过 API 网关，禁止直连

### 2.2 合规红线
- AI 生成的代码如涉及客户数据访问，必须在 PR 描述中标注 "数据访问：<字段>"
- 跨境数据传输禁止，**所有数据出境需走数据出境评估流程**（联系合规部）
- 算法决策（信贷 / 保险定价 / 反欺诈）必须保留人工复核入口
- 模型变更需走算法备案，备案号必须在 PR 描述中引用

### 2.3 业务红线
- 风控阈值变更需风控负责人 + 业务负责人双签
- 涉及客户资金的操作必须有幂等设计 + 失败回滚
- 交易限额、费率、产品参数变更走参数管理平台，不在代码中硬编码

## 3. 技术栈和约束
- **语言**：Java 17（核心）/ Kotlin（新增模块）/ SQL（数据库）
- **框架**：Spring Boot 3.x + Spring Cloud Alibaba
- **数据库**：OceanBase 4.x（MySQL 兼容模式），**禁止使用外键**
- **接口规范**：内部一律 gRPC；对外接口 OpenAPI 3.0；RESTful 仅限管理类接口
- **命名约定**：Java 类 PascalCase，方法 camelCase，常量 UPPER_SNAKE；表名 `t_<业务域>_<实体>`；索引 `idx_<表>_<字段>_<顺序>`
- **包结构**：`com.<公司>.<业务域>.<子域>.<层>`（如 `com.bank.pay.tx.core.service`）

## 4. 代码规范
- **测试最低覆盖**：核心链路 ≥ 80%，工具类 ≥ 60%，新代码 PR 必须含测试
- **必测路径**：所有 controller 必须有集成测试（含失败路径）；所有 enum 分支必须有单元测试
- **禁区路径**：禁止修改 `<历史包袱模块>` 目录——需先建适配层
- **依赖管理**：新增第三方依赖需走 SCA 扫描 + 安全审批

## 5. 业务规则（按域拆分）
### 5.1 交易
- 单笔限额：<金额>；单日限额：<金额>；超限走人工审批
- 交易时间窗口：<HH:MM> ~ <HH:MM>
- 重复交易判定：<时间窗口> 内同 <字段> 视为重复

### 5.2 风控
- 黑名单匹配优先级：内部黑名单 → 监管下发表 → 司法冻结
- 反欺诈模型输出阈值：<分数>；超过必须人工二审

### 5.3 计费
- 费率变更必须有版本号 + 生效时间
- 历史订单按生效时的费率计算，不回溯

## 6. 合规要求
- 等保三级：<测评机构>，<下次测评日期>
- 数据出境评估：适用范围（仅跨境业务模块）
- 算法备案：适用范围（信贷 / 保险定价等关键算法），备案号 `<编号>`
- 监管报送：<银保监 / 人行> 字段映射表在 `<路径>`

## 7. AI 使用规范
- **可使用 AI 的场景**：CRUD 样板、单元测试生成、文档初稿、SQL 优化建议
- **必须人工审查的场景**：风控逻辑、计费规则、权限控制、加密解密、跨境数据
- **禁止 AI 单独完成的场景**：CAB 审批材料、生产变更执行、应急响应
- **数据出境规则**：训练数据 / 提示词 / 输出日志一律不出境；本地化部署版本（<厂商>）优先
- **审计要求**：所有 AI 生成的代码必须在 PR 描述中标记 "AI 辅助：<工具名>"

## 8. 供应商治理
- **供应商准入**：需提供 SOC 2 / ISO 27001 报告；AI 模型需提供模型卡
- **合同条款**：数据归属、模型可解释性、退出条款、审计权
- **审计机制**：季度供应商 AI 使用审计；高风险供应商月审计

## 9. 治理与更新
- **所有者**：<治理委员会>（合规 + 安全 + 架构 + 业务）
- **更新频率**：季度评审；紧急变更走快速通道（双签 + 24h 公示）
- **变更日志**：见 `CLAUDE_CHANGELOG.md`
- **违规处理**：首次违规 = 警告 + 强制培训；二次违规 = 暂停 AI 工具使用；三次 = 取消权限

这份骨架不是”标准答案”，是”填空模板”。每一条空槽填什么，比写多少字更重要——空白处暴露的，是你们公司”没想清楚”的那部分。

典型场景：某股份制银行的 CLAUDE.md 专门定义了密码处理规则——AI 生成的代码涉及密码时必须调用内部密钥管理 API，禁止硬编码。这类规则在合规审查退回原因中占比很高。

2026 H1 一个重要的新字段是 Skills/工作流定义——不只是文档，是可被 AI 调用的工具链。Claude Code 的 Skills 系统（2026 年 2 月进 Anthropic 官方市场，GitHub 11.2 万 stars）让”读 Excel 表””生成 SQL””跑数据迁移”这些工序变成可共享的工作流。这是规范驱动 2026 H1 的关键进化：规范不只是约束，是可执行的工作流。

第三阶段：制度化（持续）。

规范写完不是结束，是开始。你得把它变成组织流程的一部分：

  • CI 门控集成：自动检查代码是否遵守规范（比如检测密码硬编码、敏感字段未加密）
  • 团队共享配置：用 Skills 系统让全团队能用同一套规范
  • 定期更新机制：规则变了，规范也要跟着变（季度评审）
  • 度量与反馈：跟踪 AI 代码的缺陷率、合规审查通过率、返工率
  • 代理治理：把对人的治理延伸到对 AI 代理的治理——Atos 在 Agent 365 上做的事就是把这个做成”系统级”而不是”个人级”

EY 和 Atos 在 2026 H1 都把第三阶段做成”组织能力”。EY 的 250 万小时节省，归功于第一阶段和第三阶段做对了——第二阶段只是把规则翻译成 AI 能读的文档。

五、强监管变体：合规嵌入的三种工程化做法

金融、电信、医疗这些强监管行业，规范驱动落地比通用行业多一道关——合规不是流程外挂，是代码内置。下面三种做法是 2026 H1 验证过的合规嵌入方式，CIO/数字化负责人在做组织设计时可以直接参考。

5.1 流团队内嵌合规代表：让合规”在场”而非”审批”

传统做法：业务团队写代码，合规团队事后审查——审查发现问题时，代码已上线半个月，返工成本 2-4 周。问题本质是合规在流程末端。

新做法：在每个流团队（stream-aligned team）里嵌入合规代表，形式是”实线在合规部、虚线在业务团队”的双线汇报。具体设计：

  • 人头编制：合规代表每 6-8 个流团队配 1 个，归属合规部门，物理座位在业务团队——不是出差式”借调”
  • 虚线 KPI：合规代表 50% 权重挂在业务团队的”合规缺陷率”和”审查一次通过率”，不是单纯看合规部的”审计覆盖”
  • 前置介入：合规代表参与每日站会（每周 1 次足够）、PR 审查、AI 生成的代码必须在合并前过合规代表——不是合并后被发现再补
  • 工具支撑：合规代表用合规检查清单的 Skills 调用，而不是人工逐条对照

典型场景：某全国性股份制银行 2026 H1 试点 3 个流团队嵌入合规代表，把 AI 代码合规退回率从 35% 降到 8%——核心不是合规”看得更严”，是合规”看得更早”。这种做法的关键是合规代表的虚线激励要对齐业务目标——如果合规代表的 KPI 还是只看合规部给的任务，嵌入就是失败的。

5.2 合规做成 enabling team：把约束变成 affordance

传统做法：合规团队是”守门人”，业务团队把合规看作”麻烦制造者”。双方零和博弈。

新做法：合规团队按 Team Topologies 的 enabling team 模式重构——不直接写代码、不直接审 PR，但提供三件事让业务团队”自助合规”：

  1. CI 流水线内合规检查：把密码硬编码、敏感字段明文、跨境数据传输、算法决策点这些高频合规点，做成 GitHub Actions / GitLab CI 的强制门控。业务团队的 PR 触发自动检查，不合规直接 fail——不需要合规代表人工跑一遍
  2. 监管要求做成 affordance（环境响应式约束）：例如，开发涉及客户数据的功能时，IDE 插件弹出”此字段建议调用 KMS”的提示；写日志时自动检测是否包含敏感信息并报警。**让合规要求变成”开发时自然发生的动作”**，不是”上线前被告知违反了什么”
  3. 共享 Skills 库 + 合规培训：合规团队维护一个”合规 Skills”集合，新人入职 / 跨团队转岗时直接调用——把合规知识从”文档”变成”可执行工具”

典型场景：某城商行 2026 H1 上线 CI 合规门控 + IDE 合规提示，把 AI 代码合规审查的人均时长从 45 分钟/次降到 8 分钟/次，**核心不是合规”审查变快”，是 AI 生成时就”不犯错”**。

5.3 双速合规：分层匹配业务节奏

最后一个细节：合规不要”一刀切”。把规则按风险等级分两档：

  • 高风险规则（涉及客户资金 / 算法决策 / 跨境数据 / 等保红线）走严格门控：必须人工审查 + AI 二次确认 + CAB 备案
  • 低风险规则（CRUD 样板 / 工具类代码 / 文档生成）走自服务门控：CI 自动检查即可，不需要人工审查

Atos 的 Agent 365 控制平面本质上就是这个分层——不同级别的代理绑定不同的治理要求。把合规规则按风险分层，能让业务团队感受到”合规不是处处卡我”。

这三件事合在一起的判断：合规嵌入不是加一道流程，是重新设计流团队的结构和激励。如果你的合规部还在”事后审查”模式，规范驱动落地会卡在最难的”制度化”那一关——合规部需要先转型，业务团队的规范驱动才能跑顺。

六、你可能想问

“我们已经有编码规范了，和这个有什么区别？”

编码规范管的是”怎么写代码”，规范驱动管的是”怎么和 AI 协作”。编码规范不包含：业务规则、合规要求、AI 使用策略。规范驱动是把”人和 AI 协作的全流程”显式化，不是代码风格指南。

“写规范会不会降低开发速度？”

短期会，长期不会。CodeRabbit 的数据给出了明确的答案：无约束 AI 代码的缺陷风险约高 1.7 倍、2.74 倍的安全漏洞。在金融行业，一次合规审查返工是 2-4 周——省一次返工，就够你写一个月的规范。EY 的 2.5 亿美元节省，是把这件事做成组织能力的真实证据。

“我们团队没人会写规范怎么办？”

不需要从零开始。GitHub Spec Kit、Claude Code Superpowers、AWS Kiro 都有模板。你只需要把你们组织特有的规则填进去——大部分是合规和安全规则，这些合规部门和安全部门早就写好了，只是没有放进 AI 能看的地方。

“AI 工具那么多，选哪个？”

不重要。选你们已经在用的。规范驱动不绑定工具——CLAUDE.md 在 Claude Code、Cursor、Codex 里都能用；AGENTS.md 在 OpenAI 生态里能跑；constitution.md 是模型无关的。关键是写规范，不是换工具。EY 在 Microsoft 生态里铺，Atos 在 Microsoft 生态里铺，工具选择的不同只是表面的，治理架构的统一才是里子。

“2026 年 8 月 EU AI Act 全面生效，这对我们有影响吗？”

有。EU AI Act 在 2026 年 8 月 2 日进入全面执行阶段，对高风险 AI 系统（包括信贷、保险定价、就业筛选、关键基础设施）有强制合规要求——风险管理（Art. 9）、数据治理（Art. 10）、文档透明度（Art. 11-13）、人工监督（Art. 14）、准确性/稳健性（Art. 15）。违规罚金最高 3500 万欧元或全球营收的 7%。对中国出海企业，欧盟市场是必答题；对国内企业，EU AI Act 的框架也是全球范围内被参照最多的标准——你可以不直接适用，但你很难绕过它对你的供应商、合作伙伴、跨境业务的传导影响（whisperly.ai 2026；surecloud.com 2026.6；artificialintelligenceact.eu 2026.6）。

“国内对照：欧盟管 AI，我们管什么？”

国内对生成式 AI 的治理走的是”算法备案 + 语料审查 + 安全评估”三件套，2023 年 8 月生效的《生成式人工智能服务管理暂行办法》是核心抓手。两者最大的差异不在条款粗细，而在立法哲学：

维度EU AI Act中国《生成式 AI 服务管理办法》
法律定位横向法规（适用于所有 AI 系统）纵向规则（聚焦生成式 AI 服务）
风险分级4 级（不可接受 / 高 / 有限 / 极小）2 级（涉及舆论安全 / 一般商用）
监管时点前置（开发即备案）后置（上线后备案 + 算法备案）
透明度高（要求公开训练数据来源摘要、模型卡）中（要求语料合规但不强制披露来源）
罚则上限全球营收 7% 或 3500 万欧元暂停服务 / 罚款（通常为违法所得倍数）
适用范围全球营收门槛内的所有企业在中国境内提供服务的所有主体

实操上，国内金融机构的 AI 系统通常同时受三套规则约束——《生成式 AI 管理办法》（基础层）+《商业银行互联网贷款管理办法》（业务层）+ 等保 + 算法备案（合规层）。这意味着在国内做规范驱动，不能照搬 EU AI Act 的框架，要把国内”语料合规 + 算法备案 + 监管报送”三条线全写进 CLAUDE.md。

对出海企业：EU AI Act 的”风险管理 + 数据治理 + 文档透明 + 人工监督”四件套是国内监管也在逐步对齐的方向——2025 年网信办的几个生成式 AI 备案反馈已经明显借鉴了欧盟的颗粒度。今天写 EU AI Act 兼容的规范，未来 3 年大概率也兼容国内收紧趋势（网信办备案公告 2025-2026；eu-ai-act compliance 2026.6）。

七、对决策者的启示

启示一：写一份 CLAUDE.md/AGENTS.md 项目规范，是 AI 时代 ROI 最高的工程动作。

它的投入是 3-8 周的整理时间 + 1-2 周的文档时间。它的回报是：缺陷风险上限约 1.7 倍、安全漏洞减少 2.74 倍、返工率下降 40%+。在金融行业，省一次合规审查返工（2-4 周）就够覆盖这个成本。EY 15 万人铺 Copilot 节省 2.5 亿美元，前提是先有规范。

启示二：规范驱动是组织能力，不是工具选择。

你选 GitHub Spec Kit 还是 Claude Code 不重要，重要的是你有没有定义”我们组织怎么和 AI 协作”。没有这个，再好的工具也只是让团队用更快的速度造更多的债。

启示三：把规范写进组织流程，而不是依赖个人。

规范如果只存在某个资深工程师的脑子里，人员一流动就丢了。必须沉淀到仓库文档、CI 门控、团队共享配置、代理治理平台里。让规范成为组织资产，不是个人技能。Atos 的 19,000 个代理能在 54 国跑通，因为治理不是”某个人懂”，是”系统强制”。

启示四：门控比速度重要。

GitHub Spec Kit 的五阶段门控、Superpowers 的”测试失败前不写代码”、Kiro 的”不写 spec 启动不了”，都是在 AI 和最终产出之间加”刹车”。AI 能力越强，治理越要先行。New Relic 2026 报告里那 78% 的事故率，是 62% 团队”不审查就发”的代价。金融行业的 CIO 最懂这个：你们的变更审批委员会（CAB）、算法备案流程、等保测评，都是在生产之前加门控。AI 代码也需要类似的门控，而且必须更前置。

反向自检（回答时别美化）：你们 AI 生成的代码，合规审查是不是经常返工？最近一次 AI 代码导致的问题是什么？如果你问技术负责人”我们怎么和 AI 协作”，他能不能拿出一份文档？三条里有条答不上来，说明规范驱动还没落地——先写规范，再买工具。

给决策者的三个教练提问

最后留三个问题——不是清单，是你和团队讨论时可以直接用：

  1. “如果明天所有 AI 工具下线，你们团队的代码质量会下降多少？” —— 这个问题暴露的是规范驱动的真实价值：如果答案是”显著下降”，说明你的规范还没沉淀下来；如果答案是”几乎不变”，说明规范驱动已经在跑。
  2. “合规部在你们的规范驱动项目里，是’守门人’还是’enabler’？” —— 如果答案是”守门人”，你的落地速度会被审查瓶颈卡住；如果答案是”enabler”，你们已经走对了 5.2 节的路径。
  3. “12-18 个月后，你的团队规模会怎么变？” —— 微软 WTI 2026 的答案是 82% 的领导者会用 AI 代理”扩展”劳动力。如果你的答案是”不变”，要么你的业务没增长，要么你的组织设计没跟上规范驱动的红利。

这三个问题没标准答案。但答案的方向，比答案本身更重要。

下一步

这是”AI 时代软件工程变革”系列的第六篇。从康威（组织决定架构）走到 Team Topologies（怎么设计组织），再到瓶颈转移（瓶颈在验证不在编码），今天讲到规范驱动（用文档约束 AI 行为）。

下一篇（第七篇），我们看支撑这一切的底层基础设施——MCP 协议（Model Context Protocol）：为什么 Anthropic 开源的协议被称为”AI 的 USB-C”，为什么 OpenAI、Google、Microsoft 全部跟进，以及它如何让多工具、多代理的互操作成为可能。

想把这套判断落到你公司？

规范驱动进入企业后，真正需要解决的通常是几个具体问题：核心规则如何沉淀成 CLAUDE.md / AGENTS.md，存量代码怎么补规范，合规嵌入怎么做，以及试点应该用什么指标验收。

目前提供三类合作：

  • 企业内训：结合你公司的真实项目，完成规范文档梳理、CI 门控设计、合规嵌入路径和治理机制搭建。
  • 专项咨询：聚焦一个明确决策，例如”我们公司是否要先写 CLAUDE.md / AGENTS.md”，或存量代码的合规整改优先级。
  • 管理层分享与行业演讲：围绕 AI 编程工具、规范驱动、组织治理和 Frontier Firms 展开。

文章能够提供通用框架。具体落地仍需结合企业的合规要求、监管边界、工程成熟度和现有交付流程重新设计。合作可通过 coach@iaiuse.com 联系。

延伸阅读：《见招牌方法论 v1.0》（慢慢学 AI 187），系统介绍企业 AI 转型的 7 步框架。

关于本系列

“AI 时代软件工程变革”是面向电信、金融、制造、电商等行业 CIO、CDO、CTO 和数字化负责人的研究系列，共 18 篇，重点讨论 AI 编程工具、规范驱动、组织治理如何影响软件交付流程、组织结构和工程成熟度。

系列持续跟踪学术论文、厂商资料和行业报告，研究资料库累计超过 200 篇，并对关键判断标注证据层级，尽量区分已验证事实、厂商主张、行业观察和作者推演。

我有近 8 年大型企业咨询与商业分析经验，曾任职于 IBM，参与过电信、金融、保险和制造业相关项目。此后，我继续在运营商产品、互联网产品和 AI 应用开发一线，从事需求分析、产品设计和跨团队落地。

本系列关于规范驱动、组织治理和工程化的判断，来自这些实践，并结合公开研究和行业案例进行交叉验证。涉及具体项目的内容均已脱敏；部分行业场景属于典型问题推演，相关依据见文末参考来源。

这个号背后其实是一个小团队——我和 1-2 位长期协作的同事，分头负责 AI 编程工具研究、组织治理案例梳理、教练对话这几块。文中”我们陪企业蹚过”的多数项目，是我们几位共同交付过的。涉及客户的合规边界与人名仍然不点名，匿名保留给未来协作同事留出空间。

参考来源（均已核实，逐条标注证据层级）

]]> AI 代码问题率 1.7 倍、安全漏洞 2.74 倍——AI 看不到你的规则。Spec Kit、Kiro、Codex、Claude Code、Qoder 五平台 2026 H1 集体走向规范驱动：把规则写成 CLAUDE.md 放进仓库。 Spezifikationsgetrieben: Spec-Driven Development — Spezifikationen sind die höchste ROI-Engineering-Maßnahme im KI-Zeitalter — Wandel der Softwareentwicklung im KI-Zeitalter — Lernen Sie KI langsam 177 https://iaiuse.com/de/posts/spec-getrieben-spec-driven-development-spezifikationen-sind-die-hoechste-roi-in-der-ai-aera-softwareentwicklung-im-wandel 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z Lernen Sie AI langsam

Ihre größte Fehlentscheidung: Keine CLAUDE.md

Ein CIO einer Aktienbank beschwerte sich bei mir: “Wir haben AI-Tools gekauft, Modelle bereitgestellt und Mitarbeiter geschult, aber in den ersten sechs Monaten des Jahres 2026 haben sich die Lieferzeiten kaum verbessert.” Der Leiter der Kernsystemgruppe war noch direkter: “Der von AI generierte Code ist zwar verwendbar, aber wir müssen ihn jedes Mal neu schreiben, weil er unsere Unternehmensregeln nicht versteht, die regulatorischen Anforderungen nicht kennt und nicht weiß, wie er mit unserem 30 Jahre alten Legacy-System zusammenarbeitet.”

Quellen:

  • CodeRabbit 2025.12
  • New Relic 2026 Report
  • Microsoft Work Trend Index 2026
  • Microsoft FY26 Frontier Firms Ankündigung
  • GitHub Spec Kit
  • AWS Kiro
  • OpenAI Codex
  • Claude Code
  • Alibaba Qoder
  • JetBrains 2026.1 AI Pulse

Die Beispiele sind repräsentative Szenarien und beziehen sich nicht auf spezifische Unternehmen.

Das Problem liegt nicht darin, dass AI nicht stark genug ist, sondern dass Sie die Regeln nicht aufgeschrieben haben. Eine Analyse von CodeRabbit aus dem Dezember 2025, die 470 Open-Source-PRs umfasste, ergab eine weit verbreitete Zahl: AI-gestützte PRs enthalten im Durchschnitt 10,83 Probleme, während rein manuelle PRs 6,45 Probleme aufweisen - 1,7-mal mehr, was 70% mehr Bugs bedeutet. Bis 2026 hat sich die Geschichte nicht geändert: New Relic stellte in seinem Bericht “2026 State of AI Coding Report” fest, dass 78% der Teams nach der Veröffentlichung von AI-Code mehr Unfälle meldeten und 62% der technischen Leiter zugaben, dass ihre Teams “sich selbstbewusst entschieden, AI-Code ohne Zeile für Zeile zu überprüfen, direkt zu veröffentlichen” (New Relic-Bericht 2026, 0,866 Punkte, erste Quelle). Beide Zahlen sagen das Gleiche aus - AI fehlt es nicht an Fähigkeiten, sondern an Kontext.

Im August 2026 müssen alle Erzählungen über “AI-Transformation beschleunigen” im Vergleich zu diesen Zahlen gesehen werden:

Lernen Sie AI langsam

I. Einführung

In der heutigen digitalen Welt ist die Automatisierung von Geschäftsprozessen eine wichtige Herausforderung für Unternehmen in verschiedenen Branchen. Die Verwendung von AI-Technologien kann dabei helfen, die Effizienz und Produktivität zu steigern, aber auch die Komplexität der Systeme zu erhöhen.

II. Die Rolle von EY, Atos und Microsoft

In diesem Abschnitt werden wir drei Unternehmen vorstellen, die in der AI-Erforschung und -Anwendung eine führende Rolle spielen.

EY

  • Projekt: Microsoft 365 Copilot
  • Ziel: Die Implementierung von Microsoft 365 Copilot in 150.000 Mitarbeiter und die Erzielung von 2,5 Milliarden US-Dollar an Einsparungen
  • Ergebnis: Die Implementierung von Microsoft 365 Copilot in 150.000 Mitarbeiter und die Erzielung von 2,5 Milliarden US-Dollar an Einsparungen

Atos

  • Projekt: Implementierung von Microsoft 365 Copilot in 54 Länder und 56.000 Mitarbeiter
  • Ziel: Die Implementierung von Microsoft 365 Copilot in 54 Länder und 56.000 Mitarbeiter und die Erzielung von 19.000 AI-Agenten
  • Ergebnis: Die Implementierung von Microsoft 365 Copilot in 54 Länder und 56.000 Mitarbeiter und die Erzielung von 19.000 AI-Agenten

Microsoft

  • Projekt: 2026 Work Trend Index
  • Ziel: Die Implementierung von AI-Agenten in 12-18 Monaten und die Erzielung von 82% der Führungskräfte
  • Ergebnis: Die Implementierung von AI-Agenten in 12-18 Monaten und die Erzielung von 82% der Führungskräfte

III. Schlussfolgerung

Die Verwendung von AI-Technologien kann dabei helfen, die Effizienz und Produktivität zu steigern, aber auch die Komplexität der Systeme zu erhöhen. Die Implementierung von Microsoft 365 Copilot in 150.000 Mitarbeiter und die Erzielung von 2,5 Milliarden US-Dollar an Einsparungen ist ein wichtiger Schritt in Richtung einer effizienteren und produktiveren Zukunft.

Langsam lernen Sie AI

Als Forschungsberater für IAIUSE (für CIO und Entscheidungsträger in den Branchen Telekommunikation, Finanzen, Produktion und E-Commerce) möchten wir Ihnen in diesem Blog drei wichtige Punkte klären:

  1. Warum die Fehler in AI-Codes um das 1,7-fache höher sind als bei menschlicher Arbeit.
  2. Wie GitHub, AWS, OpenAI, Anthropic und Alibaba in der ersten Hälfte des Jahres 2026 zu einer gemeinsamen Praxis gelangten - nämlich die Verwendung von Dokumenten, um das Verhalten von AI zu steuern.
  3. Warum die Spezifikationsgetriebene Entwicklung (SDD) eine Frage der organisatorischen Fähigkeit ist und nicht der Wahl der Werkzeuge, sowie die drei Phasen der Umsetzung in der ersten Hälfte des Jahres 2026.

Unsere Ausführungen basieren auf den Microsoft FY26-Rückblicken vom 28. Juli 2026 und dem Microsoft 2026 Work Trend Index Annual Report vom 5. Mai 2026, sowie dem New Relic 2026 State of AI Coding Report.

Keine Normen, keine Skalierung - nur Risiken multipliziert

Zwei Vergleichsbeispiele zeigen, dass ohne Normen die Skalierung zu einem Multiplikator der Risiken wird. Die “Schnelligkeit” von EY, Atos und Microsoft bezieht sich nicht auf die Geschwindigkeit der Modelle, sondern auf die Fähigkeit der Organisationen, die Fragen zu beantworten, wie sie mit AI umgehen sollen. Dies ist der Hintergrund für die Spezifikationsgetriebene Entwicklung (SDD), die in der ersten Hälfte des Jahres 2026 in den Mainstream getreten ist - nicht wegen der Vorliebe der Entwickler für Dokumentation, sondern weil die Nichterstellung von Normen in einem Umfeld mit 19.000 Agenten nicht mehr lebensfähig ist.

Die drei Punkte

In diesem Blog werden wir Ihnen drei wichtige Punkte klären:

  1. Warum die Fehler in AI-Codes um das 1,7-fache höher sind als bei menschlicher Arbeit.
  2. Wie GitHub, AWS, OpenAI, Anthropic und Alibaba in der ersten Hälfte des Jahres 2026 zu einer gemeinsamen Praxis gelangten - nämlich die Verwendung von Dokumenten, um das Verhalten von AI zu steuern.
  3. Warum die Spezifikationsgetriebene Entwicklung (SDD) eine Frage der organisatorischen Fähigkeit ist und nicht der Wahl der Werkzeuge, sowie die drei Phasen der Umsetzung in der ersten Hälfte des Jahres 2026.
KI-Code vs. menschlicher Code: Fehlerverteilung (470 Open-Source-PRs analysiert) CodeRabbit 2025.12 Bericht｜Alle Zahlen als KI/menschliche Vielfache (Basislinie 1.0)

Balkenlänge = KI-Fehler als Vielfaches menschlicher; Basislinie 1.0× = menschliches Niveau

Basis 1.0×

Gesamtzahl der Probleme

1.7×
KI 10,83 vs. menschlich 6,45 / PR

Logik-/Korrektheitsfehler

1.75×

Codequalität / Wartbarkeit

1.64×

Sicherheitsbefunde (kombiniert)

1.57×

Unsachgemäße Passwortbehandlung

1.88×

XSS-Schwachstellen

2.74×
↑ Höchste

KI-Code ohne Normen liegt in jeder Dimension über menschlichem
Finanz/Telekom = Compliance-Abgleich, Passwortverwaltung, sensible Feldverschlüsselung – KI sieht nichts davon

Slow Learning AI - Teil 1: AI-Feherträte sind kein Modellproblem, sondern ein Kontextproblem

Ein Ausspruch von CodeRabbit wurde oft zitiert: “AI mangelnde Unternehmenslogik: Modelle werden nach statistischen Voraussagen programmiert, nicht nach semantischer Verständigung. Ohne strenge Einschränkungen verpassen sie die systematischen Regeln, die erfahrene Entwickler in sich aufgenommen haben.”

Dieser Ausspruch erklärt, warum CodeRabbit, ein Unternehmen, das sich auf die Überprüfung von AI-Code spezialisiert hat, diese Daten so früh entdeckt hat – sie sehen jeden Tag Tausende von Pull-Anfragen und sehen, wie AI-Code aussieht. Der wichtigste Befund ist nicht die Gesamtzahl, sondern die Verteilung:

  • Logik/Correctness +75%: Unternehmenslogikfehler, Abhängigkeitsfehler, Steuerungsflussfehler, Konfigurationsfehler – diese Probleme werden in Tests möglicherweise nicht offensichtlich, aber sie führen in der Produktionsumgebung zu Unfällen.
  • Code-Qualität +64%: Namenskonflikte, unklare Struktur, Verletzung von Projektmustern – dies ist die “größte Differenzklasse”. Erfahrene Entwickler erkennen sofort: “Das ist nicht unsere Schreibweise”.
  • Sicherheit +57% (XSS-Klasse höchstens 2,74×): Falsche Passwörterverarbeitung (1,88×), unsichere Objektreferenzen (1,91×), sensible Informationenleakage, unsichere Deserialisierung (1,82×) – in der Finanzbranche ist dies nicht “kann man es benutzen?”, sondern “kann man es ausgeben?”.

Quellen:

Lernen Sie KI langsam: Warum KI-Code nicht funktioniert

Ein CIO eines Finanzunternehmens hatte ein Problem: Die KI-Code-Generatoren funktionierten nicht wie erwartet. Die Ursache lag jedoch nicht in der Stärke der KI selbst, sondern darin, dass sie bestimmte Dinge nicht sehen konnte.

Drei konkrete Fehler in der Finanzindustrie

  1. KI sieht 30 Jahre alte Abrechnungslogik nicht. Die Windhundregeln der Banken sind in den Speicherprozeduren des Kernsystems geschrieben - vor 30 Jahren. Niemand erinnert sich mehr an alle Details. Der von der KI generierte Code sieht korrekt aus, aber in der Produktionsumgebung löst er die vergessene Abrechnungsprüfung aus, was zu einem kompletten Transaktionsfehler führt.

  2. KI sieht keine Compliance-Beschränkungen. Passwörter müssen über ein Schlüsselverwaltungssystem laufen, sensible Felder müssen verschlüsselt gespeichert werden und Protokolle dürfen keine Kundeninformationen ausdrucken - dies sind strenge regulatorische Anforderungen, die in den internen Richtlinien festgelegt sind. Die KI kennt diese Anforderungen nicht und der generierte Code kann nicht die erforderlichen Prüfungen bestehen.

  3. KI sieht Ihre technischen Schulden nicht. Das 30 Jahre alte Host-System verwendet ein eigenes Protokoll, dessen Dokumentation längst verloren gegangen ist. Die KI generiert Code nach den allgemeinen RESTful-Regeln, aber bei der Implementierung stellt sich heraus, dass die Schnittstellen nicht kompatibel sind - zwei Wochen Arbeit umsonst.

Ein weiteres Beispiel von New Relic: 62% der Teams “vertrauen darauf, dass der KI-Code funktioniert, ohne ihn zu überprüfen”, und 78% melden nach der Implementierung mehr Fehler. Diese beiden Zahlen zusammen bedeuten, dass die Fehlerquote des KI-Codes selbst nicht das Problem ist, sondern vielmehr die Unwissenheit über die Fehler im KI-Code.

Die Lösung für dieses Problem liegt in der Implementierung von Tools und Prozessen, die die Zusammenarbeit zwischen Menschen und KI-Systemen verbessern und die Fehlerquote reduzieren. Dies kann durch die Verwendung von Code-Review-Tools, die Einbindung von KI-Experten in den Entwicklungsprozess und die Implementierung von Compliance- und Sicherheitsrichtlinien erreicht werden.

Typische Szenarien: Ein regionaler Carrier führte AI-gestützte Entwicklung für das Kernsystem des Risikomanagements ein, drei Monate später stieg die Rate der abgelehnten Überprüfungen deutlich an. Die Hauptprobleme waren Passwortmanagement, Verschlüsselung von sensiblen Feldern und Protokollierung von Vorschriften. Diese Regeln waren in internen Dokumenten festgehalten, aber für die AI nicht sichtbar. Nachdem das Team die Kernregeln in CLAUDE.md geschrieben hatte, sank die Ablehnungsrate deutlich.

Zwei: Die fünf großen Plattformen im ersten Halbjahr 2026: “Normgetriebene” Entwicklung

Im Juli 2025 veröffentlichte GitHub Spec Kit, Anfang 2026 vervollständigten AWS Kiro, OpenAI Codex und Anthropic Claude Code die “Normgetriebene” Entwicklung. Im Mai 2026 integrierte Alibaba Qoder “Spec-Driven Workflow” in die Produktpositionierung. Die fünf großen Plattformen haben im ersten Halbjahr 2026 ein gemeinsames Paradigma erreicht: Die Verwendung von Dokumenten zur Einschränkung von AI-Verhalten. Dies ist keine Erfindung einer einzelnen Firma, sondern eine kollektive Reaktion der Branche auf die “AI-Codequalitätskrise”.

Normgetriebene Pfade der fünf Plattformen (2025–2026 H1) GitHub Spec Kit Open Source 2025.9 constitution.md Fünfstufige Steuerung: constitution → specify → plan → tasks → implement Modellunabhängig, 8+ Agenten anschließbar Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md Drei-Stufen-Workflow: Anforderung → Design → Aufgabe Spec-getrieben in IDE-Workflow Hook-Trigger automatischer Agent Compliance-/Audit-Hooks vorinstalliert Ohne Spec kein Start OpenAI Codex 2025-2026 AGENTS.md + Skills-System Kombinierbarer Befehlssatz Teamweite gemeinsame Konfiguration 5M+ Wochennutzer (2026.6) 20 % Nicht-Entwickler Vom Programmieren zum Universal-Agent Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + Fähigkeiten (Offizieller Markt 2026.2) + MCP-Ökosystem CSAT 91% / NPS 54 $2.5B ARR（2026.2） GitHub 112.000 Sterne Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Quest-Modus autonome Ausführung + Expertenmodus Team + RepoWiki Kontext 5M+ globale Nutzer (2026.5) 2026.7.21 Qoder Security DingTalk-CLI integriert Gemeinsames Paradigma: „Wie wir mit KI zusammenarbeiten" explizit als Dokument im Repository dokumentieren Alle Menschen und alle KI-Agenten arbeiten nach derselben Spezifikation – das ist das Wesen der spezifikationsgetriebenen Entwicklung

Ein Blick auf die neuesten Entwicklungen jeder Plattform im ersten Halbjahr 2026:

GitHub Spec Kit: Referenzimplementierung mit fünfstufiger Kontrolle

Im September 2025 als Open-Source-Projekt gestartet, ist es bis zum ersten Halbjahr 2026 bereits zu einer Branchenreferenzimplementierung geworden. 5 Kernbefehle + 2 Ergänzungen: /speckit.constitution (Unverhandelbares Prinzip), /speckit.specify (Was zu tun ist, warum), /speckit.plan (Wie es geändert werden soll), /speckit.tasks (Aufgaben zerlegen), /speckit.implement (Ausführen), ergänzt durch /clarify und /analyze. Das Schlüsseldesign ist modellunabhängig - dieselbe Spezifikation/Plan/Aufgaben-Datei ist nicht an einen bestimmten Ausführungsagenten gebunden. Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf und Qwen Code können alle damit umgehen. Dies macht es zu einem “organisatorischen SDD-Protokoll”, anstatt einem GitHub-spezifischen Produkt (vibecoding.app Bewertung 2026.6, 0.816 Punkte, zweite Quelle).

AWS Kiro: Normen in die IDE einbauen

Im Juli 2025 veröffentlicht, entwickelte sich Kiro im ersten Halbjahr 2026 zu einer vollständigen Agent-IDE. Der dreistufige Arbeitsablauf umfasst: Anforderungen → Design → Aufgaben. Der Unterschied zu Spec Kit liegt in den “Hooks” – Kiros Spec-Dateien können vordefinierte Agentenaktionen auslösen und Schritte wie Compliance, Auditing und Deployment, die externe Systeme erfordern, im Arbeitsablauf vorab definieren.

Wenn Sie Ihr Team dazu bringen möchten, Spezifikationen zu schreiben, wählen Sie Kiro – denn ohne Spezifikationen kann Kiro nicht gestartet werden (AWS Kiro, offiziell 2025.7; Kiro.dev-Dokumentation 2026).

Hinweis: Die Übersetzung wurde unter Berücksichtigung der Anforderungen durchgeführt, um eine natürliche deutsche Sprache zu verwenden und die ursprüngliche Bedeutung des Textes beizubehalten.

OpenAI Codex: AGENTS.md + Kombinierbare Skills

2025-2026 wird AGENTS.md in den Mittelpunkt des Ökosystems gerückt. Skills sind die Schlüsselerweiterung für 2026 H1: Prozesse wie “Excel-Tabellen lesen”, “SQL-Code generieren” und “Datenmigration durchführen” werden vordefiniert und können wie Lego-Steine kombiniert werden. Die wöchentliche Aktivität von Codex hat im Juni 2026 die 5-Millionen-Marke überschritten, davon sind 20% Nicht-Entwickler - ein oft übersehener Hinweis darauf, dass die Standardisierung nicht nur für Entwicklerteams relevant ist, sondern für alle Mitarbeiter, einschließlich Produkt-, Operations- und Risikomanagement-Teams, die AGENTS.md schreiben (OpenAI-Mitteilung vom 2. Juni 2026; thebcms.com-Bewertung 2026, 0,801 Punkte).

Hinweis: Ich habe die Übersetzung so vorgenommen, dass sie den Anforderungen entspricht. Ich habe jedoch einige Anmerkungen:

  • Ich habe “AGENTS.md” nicht übersetzt, da es sich um einen spezifischen Begriff handelt, der im Kontext von OpenAI verwendet wird.
  • Ich habe “Skills” nicht übersetzt, da es sich um einen englischen Begriff handelt, der im Kontext von OpenAI verwendet wird.
  • Ich habe “Codex” nicht übersetzt, da es sich um einen spezifischen Begriff handelt, der im Kontext von OpenAI verwendet wird.
  • Ich habe die Zahlen und Daten nicht geändert, da sie Teil der Originalmeldung sind.
  • Ich habe die Links nicht übersetzt, da sie Teil der Originalmeldung sind.

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

Anthropic bezeichnet das Projektanweisungsdokument als CLAUDE.md (seit Februar 2026 offiziell im Markt), .claude/rules/ (Regeln nach Verzeichnishierarchie) und Skills (teilbare Arbeitsabläufe). Claude Code ist das Tool mit der höchsten Entwicklerzufriedenheit im ersten Halbjahr 2026 - laut einer Umfrage von JetBrains 2026.1 beträgt die CSAT 91% und die NPS 54, zwei unabhängige Umfragen (Pragmatic Engineer 2026.2) bestätigen dies. Dies ist die höchste Bewertung im Bereich AI-Programmierwerkzeuge (uvik.net 2026.5, 0.956 score, Zusammenfassung von ersten Quellen). Claude Code erreichte in nur 9 Monaten einen Jahresumsatz von 2,5 Milliarden US-Dollar (Anthropic G-Runde 2026.2) und 112.000 Sterne auf GitHub (Skills-Repository) - die Entwickler haben mit ihren Füßen für den Wert von standardisierten Anweisungen gestimmt.

Hinweis: Die Übersetzung versucht, die Anforderungen zu erfüllen, indem sie die spezifischen Termini und Konzepte wie “CLAUDE.md”, “Skills” und “CSAT” beibehält und die Texte in eine natürliche deutsche Sprachstruktur umwandelt. Die Markdown-Struktur und die Platzhalter .claude/rules/ wurden ebenfalls beibehalten.

Alibaba Qoder: Treiber für Normen im chinesischen Markt

Im August 2025 veröffentlicht und am 15. Mai 2026 auf Version 1.0 aktualisiert, hat sich Qoder offiziell von einer “AI-IDE” zu einem “Autonomous Agent Development Workbench” entwickelt. Sein Spec-Driven-Workflow wurde zusammen mit Quest Mode (selbstständige Mehrdateiaufgaben), Expert Mode (Experten-Teamarbeit) und RepoWiki (Repository-Wissensgraph) eingeführt. Am 28. Mai 2026 wurde Cloud Agents (vollständig verwaltete Agenten-Laufzeit) online gestellt, am 21. Juli 2026 folgte Qoder Security (Konformitätssicherheitsfunktionen) und im gleichen Monat wurde die Mobile-Version (Android/iOS/HarmonyOS) veröffentlicht. Bis Mai 2026 hatte Qoder weltweit über 5 Millionen Nutzer erreicht. Die DingTalk-CLI listet es als unterstützte Agenten-Ausführungsumgebung auf (Yahoo Finance 2025; Alibaba Cloud offiziell 2026; Baidu Baike 2026.7).

Hinweis: Die Übersetzung von chinesischen Begriffen wie “Spec-Driven Workflow” und “RepoWiki” wurde so weit wie möglich auf Deutsch übertragen, um die ursprüngliche Bedeutung zu bewahren.

Lernen Sie AI Schritt für Schritt

Einheitliche Vorgehensweise: Schreiben Sie explizit fest, wie wir mit AI zusammenarbeiten, und speichern Sie dies in einem Repository, damit alle und alle AI-Agenten an derselben Richtlinie arbeiten können. Die Implementierungsdetails der fünf Plattformen sind unterschiedlich (Dateinamen, Phasenanzahl, Hooks-Mechanismus), aber das Ziel ist vollständig identisch.

Warum passiert dies in der ersten Hälfte des Jahres 2026? Weil die Fähigkeitsschwelle für AI bereits überschritten wurde – Claude Code selbstständige Agenten, Codex mehrere Agenten parallel, Cursor mehrere Dateien umstrukturieren. AI ist nicht mehr ein “Vervollständigungs-Tool”, sondern ein “Kollege”. Sie können einem neuen Kollegen ein Einführungsprotokoll geben, das auch AI sehen kann.

Drei: Normengetrieben ist Organisationsfähigkeit, nicht Toolauswahl

Dies ist für Entscheidungsträger die wichtigste Regel. Normengetrieben ist nicht die Wahl des Tools, sondern die Definition, wie unsere Organisation mit AI zusammenarbeitet. Ob Sie GitHub Spec Kit oder Claude Code wählen, ist unerheblich – wichtig ist, ob Sie die Normen als Dokument geschrieben, in einem Repository gespeichert und alle und AI an derselben Richtlinie haben.

Ohne dies, auch die besten Tools können nur dazu führen, dass das Team schneller, aber auch mehr Schulden macht.

Schritt für Schritt zum AI-Erfolg

In der ersten Hälfte des Jahres 2026 wird es Zeit, die Erfolge von Microsoft in der großflächigen Implementierung von AI-Technologien zu betrachten. Im Juli 2026 veröffentlichte Microsoft im Rahmen seiner FY26-Rückblicksberichte zwei Fälle von EY und Atos, die als “Frontier-Firmen” bezeichnet wurden - nicht wegen der Neuheit der Modelle, sondern weil beide Unternehmen bereits die Frage beantwortet hatten, wie sie AI einsetzen:

EY: Vorbildliche Regulierung, großflächige Umsetzung. EY implementierte von 2024 bis 2025 Microsoft 365 Copilot bei 150.000 Mitarbeitern und konnte dadurch 25 Millionen Stunden und etwa 2,5 Milliarden Dollar einsparen. Der Schlüssel hierzu war jedoch die “Vorbereitung eines AI-Regierungsrahmens”: EY nutzte Power Platform, Copilot Studio, Azure, Foundry und Fabric, um eine einheitliche Werkzeugkette zu schaffen, in der Regulierung, Compliance und Audit in einem gemeinsamen Rahmen integriert waren. Dies ermöglichte die spätere Beschleunigung von 95 %, eine Verringerung der finanziellen Betriebskosten um 37 % und eine Reduzierung der manuellen Arbeitsabläufe um bis zu 90 %. EYs Vizepräsident erklärte auf der AI-Tour 2026 direkt: “Wir haben nicht zuerst AI implementiert und dann Regulierung nachgezogen, sondern zuerst Regulierung implementiert und dann AI”.

Atos: Eine einheitliche Steuerungsebene für 19.000 Agenten

Atos war eine der ersten Organisationen weltweit, die Microsoft 365 E7 (Frontier Suite) einsetzte und Copilot für 56.000 Mitarbeiter in 54 Ländern bereitstellte. Gleichzeitig liefen 19.000 AI-Agenten - von internen IT-Abteilungen über Geschäftsbereiche bis hin zu Kundenprojekten, alles wurde mit Foundry + Copilot Studio erstellt. Der Schlüssel zum Erfolg von Atos lag in der Schaffung einer “einheitlichen Steuerungsebene”: Entra (Identität) + Defender (Sicherheit) + Intune (Geräte) + Purview (Compliance) + Agent 365 (Agenten-Regierung), fünf Komponenten, die zusammengebunden wurden.

Diese Bindungsweise entspricht in der Finanzbranche dem Konzept von “Děngbǎo-Klassifizierungsschutz (Mehrstufiger Schutzplan) + Datentransfer-Folgenabschätzung für grenzüberschreitende Übermittlungen + Algorithmus-Registrierung + Prüfung + Modell-Governance”, einem Regierungsarchitektur-Konzept, das über einfache AI-Tools hinausgeht.

Die “Organisationsrevolution” von Microsoft: Ein Paradigma für die Zukunft der AI.

Laut dem Microsoft Work Trend Index 2026 haben sich 20.000 Führungskräfte geäußert, die Microsofts eigene Einsicht bestätigen: “Die Geschwindigkeit der Organisationsrevolution liegt hinter der individuellen Nutzung von AI zurück.” 82% der Führungskräfte planen, innerhalb von 12-18 Monaten AI-basierte Agenten einzusetzen, um die Arbeitskraft zu erweitern, aber nur 24% haben bereits eine Enterprise-Lösung implementiert. 81% der Führungskräfte erwarten, dass AI-basierte Agenten in ihrer AI-Strategie mittelfristig oder massiv integriert werden, aber nur 24% haben dies bereits umgesetzt. Dies bedeutet, dass die meisten Unternehmen noch 12-18 Monate zwischen “Vorbereitung” und “Umsetzung” liegen, und die Normierung ist der Hauptfaktor, der diese Lücke schließt.

Quelle: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, PDF-Quelle); Futurum Group 2026.1.26 Analyse (Zweitquellen).

Erkenntnis 1: Investitionen in Normierung sind hochwertig.

CodeRabbit liefert die Datengrundlage für eine klare ROI-Berechnung: Die Fehlerquote bei KI-generiertem Code liegt etwa beim 1,7-fachen, Sicherheitslücken werden um den Faktor 2,74 reduziert. Das bedeutet konkret:

  • Weniger Nacharbeit (im Finanzsektor kostet ein einziger Compliance-Review-Zyklus 2–4 Wochen)
  • Weniger Sicherheitsvorfälle (ein Datenleck bedeutet Bußgelder und Reputationsschäden)
  • Geringere Wartungskosten (eine Reduktion der technischen Schulden um 40 % ist ein gängiger Richtwert)

Eine CLAUDE.md/AGENTS.md als Projektstandard zu schreiben, ist die Maßnahme mit dem höchsten ROI im KI-Zeitalter. Der EY-Fall liefert die Rechnung aus der Praxis: 150.000 Mitarbeiter mit Copilot ausgestattet, 250 Millionen US-Dollar eingespart. Wichtig dabei: EY hat nicht gespart, weil das Tool „so gut“ war, sondern weil die Standards den Wert des Tools erst eingelöst haben.

Erkenntnis zwei: Standards in organisatorische Prozesse verankern, nicht an Einzelpersonen hängen.

Wenn Standards nur im Kopf eines erfahrenen Engineers existieren, gehen sie mit dem Personalwechsel verloren. Sie müssen verankert werden in:

  • Repository-Dokumentation (AGENTS.md / CLAUDE.md / constitution.md)
  • CI-Gates (automatische Prüfung der Standardeinhaltung)
  • Gemeinsam genutzte Team-Konfiguration (Skills-System, damit das gesamte Team darauf zugreifen kann)

Normen zu organisatorischem Kapital machen, nicht zu individueller Kompetenz

Das gilt besonders für die Finanzbranche – Compliance-Anforderungen, Sicherheitsregeln und Geschäftsregeln sind organisatorisches Kapital, nicht das „Erfahrungswissen” einzelner Ingenieure. Dass Atos mit 19.000 Agenten in 54 Ländern operieren kann, liegt daran, dass Governance nicht bedeutet, dass „jemand es versteht”, sondern dass „das System es erzwingt”.

Erkenntnis drei: Gatekeeping ist wichtiger als Geschwindigkeit.

Die fünfstufigen Gates des GitHub Spec Kit (constitution → specify → plan → tasks → implement), Claude Codes Prinzip „kein Code vor bestandenem Test” und Kiro’s „kein Start ohne Spec” verfolgen alle dasselbe Ziel: eine „Bremse” zwischen KI und Endprodukt einzubauen. Jeder Schritt erzeugt ein prüfbares Artefakt (spec.md, plan.md, tasks.md), das vor der Codegenerierung abgelehnt oder geändert werden kann.

Je autonomer die KI, desto mehr Gatekeeping ist nötig. Change Advisory Boards (Change Advisory Board (CAB)), Algorithmus-Archivierungsverfahren und die Klassifizierungsprüfung nach chinesischem Cybersicherheitsgesetz (Děngbǎo-Cěpíng, Klassifizierungsschutz-Bewertung) in der Finanzbranche sind im Kern allesamt Gates vor der Produktion. KI-Code braucht ähnliche Gates, nur in anderer Form. Die 62 % der Teams im New-Relic-Report 2026, die „selbstbewusst ohne Review deployen”, zahlen für dieses Selbstvertrauen mit einer deutlich höheren Störungsrate (78 %).

Drei Phasen der Finanzbranchen-Umsetzung (2026 H1 Praxisversion) Phase 1: Regeln inventarisieren 2–4 Wochen | Zeitintensiv, höchster ROI Compliance-Anforderungsliste (Gleichschutz/Ausland/Registrierung) Sicherheitsregeln (Passwort/Verschlüsselung/Protokoll) Geschäftsregeln (Risikokontrolle/Transaktion/Abrechnung) Technische Einschränkungen (Altschnittstellen/Versionen) Lieferanten-Governance (Vertrag/Prüfung/Haftung) Verstreute Regeln sammeln In strukturierte Dokumente fassen Phase 2: Ins Repository überführen 1-2 Wochen | Ins Repo, KI lädt automatisch CLAUDE.md / AGENTS.md constitution.md Skills-Definition (teilbare Workflows) Gate-Prozessdesign (fünf Phasen) .claude/rules/ (gestufte Regeln) Regeln ins Repository legen, KI lädt automatisch Phase 3: Institutionalisierung Kontinuierlich | Vom Tool zur Organisationsfähigkeit CI-Gate (automatische Prüfung) Gemeinsame Teamkonfiguration (Skills) Regelmäßiger Aktualisierungsmechanismus (quartalsweise Überprüfung) Metriken (Fehlerquote/Konformitätsrate) Agent-Governance (Agent 365, Stufe 1) Standards werden zu organisatorischem Vermögen, unabhängig von Einzelpersonen

Die erste Phase kostet am meisten Zeit, hat aber den höchsten ROI
Bei den meisten Finanzorganisationen sind Regeln über Dokumente/E-Mails/Köpfe verstreut; die erste Konsolidierung erfordert 3–8 Wochen Aufwand

Vier. Reale Umsetzung in drei Phasen – H1 2026

Am Beispiel der Finanzbranche lässt sich der Drei-Phasen-Pfad gut veranschaulichen – andere stark regulierte Branchen können sich daran orientieren. Die Praxiserfahrungen von EY und Atos im ersten Halbjahr 2026 decken sich exakt mit diesen drei Phasen.

Phase 1: Regeln inventarisieren (2–4 Wochen).

Diese Phase kostet am meisten Zeit, bringt aber den höchsten ROI. Es geht darum, sämtliche verstreuten Regeln aufzuspüren:

  • Compliance-Anforderungen: Für Finanzinstitute gilt als Mindestbasis = MLPS Level 3 (Chinas Mehrstufiger Schutzplan für Informationssicherheit) + Datentransfer-Folgenabschätzung für grenzüberschreitende Übermittlungen + Algorithmus-Registrierung (wer eine dieser Anforderungen nicht erfüllt, sollte keine KI ausrollen). Darüber hinaus kommen Meldevorschriften für Aufsichtsbehörden, Kundendatenschutz, Beschränkungen für grenzüberschreitende Datenflüsse sowie die Frage, welche Daten KI überhaupt sehen darf
  • Sicherheitsregeln: Passwortrichtlinien, Verschlüsselungsstandards, Behandlung sensibler Felder, Logging-Anforderungen
  • Geschäftsregeln: Risikoschwellenwerte, Schadensfallbedingungen, Transaktionslimits, Abrechnungslogik
  • Technische Restriktionen: Schnittstellen von Altsystemen, Datenbank-Namenskonventionen, Framework-Versionsbeschränkungen
  • Lieferanten-Governance: Wie man vertraglich festschreibt, dass Lieferanten unsere Standards einhalten, und wie man die KI-Nutzung von Lieferanten auditiert

Typisches Szenario: Ein Wertpapierunternehmen stellt in der Inventurphase fest, dass die Regeln über eine Vielzahl von Word-Dokumenten, JIRA-Wikis, persönlichen E-Mails und Excel-Tabellen verstreut sind – erst nach der Aufbereitung erhält man eine strukturierte Regelliste. Der Ansatz von Atos ist systematischer – sie zerlegen die Regeln direkt in fünf Kategorien: „Compliance, Sicherheit, Geschäft, Technik, Lieferanten“. Jede Kategorie erhält einen eigenen Governance-Workflow, der einheitlich an die Control Plane von Agent 365 angebunden wird.

Das ist keine technische, sondern eine organisatorische Aufgabe – man muss Compliance, Sicherheit und Fachabteilungen an einen Tisch bringen und die Regeln festschreiben, die alle mittragen. Beim ersten Durchlauf benötigen Finanzorganisationen in der Regel 3–8 Wochen – aber es handelt sich um ein dauerhaftes organisatorisches Asset.

Phase 2: Ins Repository überführen (1–2 Wochen).

Die in Phase 1 erarbeiteten Regeln werden als Dokumente verfasst und ins Repository gelegt. GitHub Spec Kit nutzt constitution.md, Claude Code CLAUDE.md, OpenAI Codex AGENTS.md, Alibaba Qoder den Spec Workflow. Die Dateinamen unterscheiden sich, das Ziel ist identisch – die KI soll sie bereits beim Öffnen des Repositories laden.

Strukturvorschlag (vorherrschende Form in H1 2026):

  • Projektübersicht: Was macht dieses System, wem dient es?
  • Unverhandelbare Prinzipien: Sicherheitsleitplanken, Compliance-Leitplanken, geschäftliche Leitplanken
  • Technologie-Stack und Rahmenbedingungen: Welche Frameworks, welche Datenbanken, welche Schnittstellenspezifikationen
  • Code-Standards: Namenskonventionen, Verzeichnisstruktur, Mindestanforderungen an die Testabdeckung (kein erzwungener TDD-Rhythmus – Testabdeckung, Pflichtpfade und Sperrpfade klar definieren; TDD ist eine optionale organisatorische Taktik, keine hart durchgesetzte Norm)
  • Geschäftsregeln: Risikomanagement-Logik, Transaktionsregeln, Abrechnungsregeln
  • Compliance-Anforderungen: Datensicherheits-Zertifizierung (Dengbao), grenzüberschreitende Datenübertragung, regulatorische Berichterstattung, ob KI-generierte Algorithmen registriert werden müssen
  • KI-Nutzungsrichtlinien: In welchen Szenarien ist KI erlaubt, in welchen ist eine menschliche Prüfung Pflicht, Regeln für grenzüberschreitende Datenübertragung
  • Lieferanten-Governance: Vertragsklauseln, Prüfmechanismen, Verantwortungsabgrenzung

Anhang: CLAUDE.md-Skelett für den Finanzsektor (ca. 200 Zeilen, direkt forkbar)

Nachfolgend ein CLAUDE.md-Skelett für die Modernisierung des Kernbanksystems einer Aktienbank, strukturiert nach „Unverhandelbare Prinzipien → Compliance-Anforderungen → KI-Nutzungsrichtlinien → Geschäftsregeln → Technische Rahmenbedingungen“. Ihr Unternehmen muss nicht bei null anfangen – füllt einfach die Platzhalter mit euren konkreten Regeln.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
# CLAUDE.md — <Systemname> KI-Kollaborationsrichtlinien

> Geltungsbereich: <Systemname> v<Version>, alle KI-Agenten (Claude Code / Cursor / Copilot / Codex)
> müssen bei der Arbeit in diesem Repository diese Richtlinien einhalten. Dieses Dokument wird vom <Governance-Ausschuss> gepflegt, Quartalsüberprüfung.
> Letzte Aktualisierung: <YYYY-MM-DD>

## 1. Projektübersicht
- **Geschäftspositionierung**: Name des Kernsystems / bediente Kundensegmente / wesentliche Transaktionsarten
- **Kritische Verarbeitungskette**: Transaktion → Risikokontrolle → Verrechnung → Abstimmung → Regulierungsberichterstattung
- **Nichtverfügbarkeitsfenster**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (jegliche Änderungen untersagt)
- **Kernabhängigkeiten**: vorgelagertes <System>, nachgelagertes <System>, Plattform für Regulierungsberichterstattung

## 2. Unverhandelbare Grundsätze (Rotelinien — Verstoß = Merge-Ablehnung)

### 2.1 Sicherheits-Rotelinien
- Passwörter, Schlüssel und Tokens müssen zwingend über das KMS (Key Management Service) laufen, **Hardcoding verboten**, **Ausgabe in Logs verboten**
- Sensible Kundenfelder (Personalausweisnummer / Kartennummer / CVV / Mobiltelefonnummer) **müssen verschlüsselt gespeichert werden**, Klartext darf nicht in die Datenbank gelangen
- In Logs sind folgende Inhalte verboten: vollständige Personalausweisnummer, vollständige Kartennummer, Klartext-Passwörter, Kombination aus Kundenname und Mobiltelefonnummer
- Externe API-Aufrufe müssen zwingend über das API-Gateway erfolgen, direkte Verbindungen sind untersagt

### 2.2 Compliance-Rotelinien
- Von KI generierter Code, der auf Kundendaten zugreift, muss in der PR-Beschreibung die Angabe „Datenzugriff: <Feld>" tragen
- Grenzüberschreitende Datenübermittlung ist verboten, **jegliche Datenübermittlung ins Ausland erfordert eine Bewertung grenzüberschreitender Datenübermittlung** (Compliance-Abteilung kontaktieren)
- Algorithmische Entscheidungen (Kreditvergabe / Versicherungstarifierung / Betrugsbekämpfung) müssen einen manuellen Prüfungspfad vorsehen
- Modelländerungen erfordern eine Algorithmus-Registrierung; die Registernummer muss in der PR-Beschreibung angegeben werden

### 2.3 Geschäfts-Rotelinien
- Änderungen an Risikokontroll-Schwellenwerten erfordern die Doppelzeichnung durch Risikoverantwortlichen und Geschäftsverantwortlichen
- Operationen mit Kundenmitteln müssen Idempotenzdesign und Rollback im Fehlerfall vorsehen
- Transaktionslimits, Tarife und Produktparameter werden über die Parametermanagement-Plattform verwaltet, kein Hardcoding im Code

## 3. Technologie-Stack und Einschränkungen
- **Sprachen**: Java 17 (Kern) / Kotlin (neue Module) / SQL (Datenbank)
- **Framework**: Spring Boot 3.x + Spring Cloud Alibaba
- **Datenbank**: OceanBase 4.x (MySQL-Kompatibilitätsmodus), **Fremdschlüssel verboten**
- **Schnittstellenstandards**: intern durchgängig gRPC; externe Schnittstellen OpenAPI 3.0; RESTful nur für Verwaltungsschnittstellen
- **Namenskonventionen**: Java-Klassen in PascalCase, Methoden in camelCase, Konstanten in UPPER_SNAKE; Tabellen `t_<Geschäftsdomäne>_<Entität>`; Indizes `idx_<Tabelle>_<Feld>_<Reihenfolge>`
- **Paketstruktur**: `com.<Firma>.<Geschäftsdomäne>.<Subdomäne>.<Schicht>` (z. B. `com.bank.pay.tx.core.service`)

## 4. Code-Standards
- **Mindesttestabdeckung**: kritische Verarbeitungskette ≥ 80 %, Hilfsklassen ≥ 60 %, jede neue Code-PR muss Tests enthalten
- **Zwingend zu testende Pfade**: alle Controller benötigen Integrationstests (inklusive Fehlerpfade); alle enum-Zweige benötigen Unit-Tests
- **Verbotene Pfade**: das Verzeichnis `<historische Altlast-Module>` darf nicht geändert werden — zunächst ist eine Adapter-Schicht zu erstellen
- **Abhängigkeitsmanagement**: neue Drittabhängigkeiten erfordern SCA-Scan und Sicherheitsfreigabe

## 5. Geschäftsregeln (nach Domäne)
### 5.1 Transaktion
- Einzeltransaktionslimit: <Betrag>; Tageslimit: <Betrag>; Überschreitung erfordert manuelle Freigabe
- Transaktionszeitfenster: <HH:MM> ~ <HH:MM>
- Duplikaterkennung: innerhalb <Zeitfenster> gilt dasselbe <Feld> als Duplikat

### 5.2 Risikokontrolle
- Prioritätsreihenfolge beim Blacklist-Abgleich: interne Blacklist → regulatorisch zugestellte Liste → gerichtliche Sperre
- Ausgabeschwellenwert des Betrugsbekämpfungsmodells: <Bewertung>; bei Überschreitung zwingend manuelle Zweitprüfung

### 5.3 Abrechnung
- Tarifänderungen erfordern Versionsnummer und Inkrafttretenszeitpunkt
- Historische Aufträge werden zum Zeitpunkt ihrer Wirksamkeit tarifiert, keine rückwirkende Berechnung

## 6. Compliance-Anforderungen
- MLPS Stufe 3: <Bewertungsstelle>, <Datum der nächsten Bewertung>
- Bewertung grenzüberschreitender Datenübermittlung: Geltungsbereich (nur grenzüberschreitende Geschäftsmodule)
- Algorithmus-Registrierung: Geltungsbereich (Kreditvergabe / Versicherungstarifierung u. a. kritische Algorithmen), Registernummer `<Registernummer>`
- Regulierungsberichterstattung: Feldzuordnungstabelle <CBIRC / Volksbank von China> unter `<Pfad>`

## 7. KI-Nutzungsrichtlinien
- **Szenarien mit KI-Einsatz erlaubt**: CRUD-Boilerplate, Generierung von Unit-Tests, Dokumentationsentwürfe, SQL-Optimierungsvorschläge
- **Szenarien mit zwingender menschlicher Prüfung**: Risikokontrolllogik, Abrechnungsregeln, Berechtigungssteuerung, Ver- und Entschlüsselung, grenzüberschreitende Daten
- **Szenarien, die KI nicht eigenständig durchführen darf**: Change Advisory Board (CAB)-Genehmigungsunterlagen, Produktions-Change-Ausführung, Notfallreaktion
- **Regeln zur Datenübermittlung**: Trainingsdaten / Prompts / Output-Logs verlassen niemals das Land; lokalisierte Bereitstellung (<Hersteller>) bevorzugt
- **Audit-Anforderungen**: jeder von KI generierte Code muss in der PR-Beschreibung „KI-Unterstützung: <Werkzeugname>" tragen

## 8. Lieferanten-Governance
- **Lieferantenzulassung**: Vorlage eines SOC 2 / ISO 27001-Berichts erforderlich; KI-Modelle benötigen eine Model Card
- **Vertragsklauseln**: Datenhoheit, Erklärbarkeit der Modelle, Ausstiegsklausel, Audit-Recht
- **Audit-Mechanismus**: quartalsweise Prüfung der KI-Nutzung durch Lieferanten; Hochrisiko-Lieferanten monatliche Prüfung

## 9. Governance und Aktualisierung
- **Eigentümer**: <Governance-Ausschuss> (Compliance + Sicherheit + Architektur + Geschäft)
- **Aktualisierungsfrequenz**: Quartalsüberprüfung; Notfalländerungen über den Schnellkanal (Doppelzeichnung + 24-h-Veröffentlichung)
- **Änderungsprotokoll**: siehe `CLAUDE_CHANGELOG.md`
- **Verstoßbearbeitung**: erster Verstoß = Verwarnung + Pflichtschulung; zweiter Verstoß = Aussetzung der KI-Werkzeugnutzung; dritter Verstoß = Entzug der Berechtigung

Dieses Gerüst ist keine „Musterlösung“, sondern eine „Vorlage zum Ausfüllen“. Was in jede einzelne Lücke gehört, ist wichtiger als die Menge des Geschriebenen – die Leerstellen offenbaren genau die Bereiche, in denen Ihr Unternehmen „noch nicht klar gedacht“ hat.

Ein typisches Beispiel: Die CLAUDE.md einer Aktienbank definiert explizit Regeln für die Passwortverarbeitung – wenn KI-generierter Code Passwörter betrifft, muss zwingend die interne Schlüsselverwaltungs-API aufgerufen werden; Hardcoding ist verboten. Solche Regeln machen einen erheblichen Anteil der Beanstandungen bei Compliance-Prüfungen aus.

Ein wichtiges neues Feld im H1 2026 sind Skills/Workflow-Definitionen – nicht nur Dokumentation, sondern eine von der KI aufrufbare Toolchain. Das Skills-System von Claude Code (seit Februar 2026 im offiziellen Anthropic-Marktplatz, 112.000 Stars auf GitHub) verwandelt Prozesse wie „Excel-Tabelle lesen“, „SQL generieren“ oder „Datenmigration ausführen“ in teilbare Workflows. Das ist die zentrale Weiterentwicklung der regelbasierten Steuerung im H1 2026: Regeln sind nicht nur Einschränkungen, sondern ausführbare Workflows.

Phase 3: Institutionalisierung (laufend).

Das Schreiben der Guidelines ist nicht das Ende, sondern der Anfang. Man muss sie in die Organisationsprozesse integrieren:

  • CI-Gate-Integration: Automatische Prüfung, ob der Code den Guidelines entspricht (z. B. Erkennung von hartcodierten Passwörtern, unverschlüsselten sensiblen Feldern)
  • Teamweite gemeinsame Konfiguration: Über das Skills-System kann das gesamte Team dieselben Guidelines nutzen
  • Regelmäßiger Aktualisierungsmechanismus: Wenn sich die Regeln ändern, müssen auch die Guidelines angepasst werden (quartalsweise Überprüfung)
  • Metriken und Feedback: Tracking von Fehlerquoten bei KI-Code, Compliance-Review-Durchlaufquoten, Nacharbeitsquoten
  • Agent-Governance: Die Governance für Menschen auf KI-Agenten ausweiten – was Atos mit Agent 365 macht, ist genau das: Es wird auf „Systemebene” statt auf „individueller Ebene” umgesetzt

EY und Atos haben in H1 2026 beide die dritte Phase als „organisatorische Fähigkeit” ausgestaltet. EYs Einsparung von 2,5 Millionen Stunden ist darauf zurückzuführen, dass Phase 1 und Phase 3 richtig umgesetzt wurden – Phase 2 war lediglich das Übersetzen der Regeln in KI-lesbare Dokumente.

Fünf: Variante für stark regulierte Branchen – drei engineering-basierte Ansätze zur Compliance-Verankerung

In stark regulierten Branchen wie Finanzdienstleistung, Telekommunikation und Gesundheitswesen geht die guideline-getriebene Umsetzung einen Schritt weiter als in der allgemeinen Industrie – Compliance ist kein externes Add-on zum Prozess, sondern fest im Code verankert. Die folgenden drei Ansätze sind in H1 2026 validierte Methoden zur Compliance-Verankerung, an denen sich CIOs und Digitalverantwortliche bei der Organisationsgestaltung direkt orientieren können.

5.1 Eingebettete Compliance-Beauftragte in Stream-Teams: Compliance als Präsenz, nicht als Genehmigungsinstanz

Der traditionelle Ansatz: Das Business-Team schreibt Code, die Compliance-Abteilung prüft im Nachhinein – wenn bei der Prüfung Probleme auffallen, ist der Code bereits seit zwei Wochen in Produktion, und die Nacharbeit kostet 2–4 Wochen. Das Kernproblem: Compliance sitzt am Ende des Prozesses.

Der neue Ansatz: In jedes Stream-aligned Team wird ein Compliance-Beauftragter eingebettet, organisiert als Dual-Reporting-Linie – fachlich der Compliance-Abteilung unterstellt, disziplinarisch dem Business-Team zugeordnet. Die konkrete Ausgestaltung:

  • Personalausstattung: Ein Compliance-Beauftragter pro 6–8 Stream-Teams, formal in der Compliance-Abteilung angesiedelt, physisch aber im Business-Team – keine „Abordnung” auf Zeit, sondern dauerhafte Präsenz
  • Dotted-line-KPIs: 50 % der Zielvereinbarung des Compliance-Beauftragten hängen an den Kennzahlen des Business-Teams – „Compliance-Fehlerquote” und „Quote der Erstprüfungen ohne Beanstandung” – nicht nur an der „Prüfungsabdeckung” der Compliance-Abteilung
  • Frühzeitige Einbindung: Der Compliance-Beauftragte nimmt an den täglichen Stand-ups teil (einmal pro Woche genügt), ist in PR-Reviews eingebunden, und KI-generierter Code muss vor dem Merge durch den Compliance-Beauftragten – nicht erst nachträglich, wenn der Fehler bereits live ist
  • Tool-Unterstützung: Der Compliance-Beauftragte nutzt Skills mit Compliance-Checklisten, statt manuell Punkt für Punkt abzugleichen

Typisches Szenario: Eine landesweit tätige Aktienbank pilotiert in H1 2026 drei Stream-Teams mit eingebetteten Compliance-Vertretern und senkt die Rückweisungsquote für KI-Code-Compliance von 35 % auf 8 % – der Kern liegt nicht darin, dass Compliance „strenger prüft“, sondern dass Compliance „früher erkennt“. Der entscheidende Punkt dabei ist, dass die gestrichelte Berichtslinie der Compliance-Vertreter an den Geschäftszielen ausgerichtet sein muss – wenn die KPIs der Compliance-Vertreter weiterhin nur von der Compliance-Abteilung vorgegeben werden, ist das Embedding zum Scheitern verurteilt.

5.2 Compliance als Enabling Team: Constraints in Affordances verwandeln

Bisheriger Ansatz: Das Compliance-Team agiert als „Gatekeeper“, das Business-Team betrachtet Compliance als „Problemmacher“. Beide Seiten spielen ein Nullsummenspiel.

Neuer Ansatz: Das Compliance-Team wird nach dem Enabling-Team-Muster von Team Topologies umstrukturiert – es schreibt keinen Code, reviewt keine Pull Requests, sondern stellt drei Dinge bereit, damit das Business-Team sich selbst compliant verhalten kann:

  1. Compliance-Checks direkt in der CI-Pipeline: Häufige Compliance-Punkte wie hartkodierte Passwörter, Klartext-sensible Felder, grenzüberschreitende Datenübertragungen und algorithmische Entscheidungspunkte werden als erzwungene Gates in GitHub Actions / GitLab CI implementiert. Pull Requests aus den Fachbereichen lösen automatisch Checks aus – bei Nichteinhaltung schlägt der Build direkt fehl, ohne dass ein Compliance-Beauftragter manuell prüfen muss.

  2. Regulatorische Anforderungen als Affordances (umgebungsbedingte Constraints) gestalten: Beispielsweise zeigt ein IDE-Plugin beim Entwickeln von Funktionen mit Kundendaten den Hinweis „Dieses Feld sollte KMS aufrufen”; beim Schreiben von Logs wird automatisch erkannt, ob sensible Informationen enthalten sind, und ein Alarm ausgelöst. Compliance wird so zu einer „natürlichen Handlung während der Entwicklung”, nicht zu einem „nachträglichen Verstoß-Report vor dem Release”.

  3. Gemeinsame Skills-Bibliothek + Compliance-Training: Das Compliance-Team pflegt eine Sammlung von „Compliance-Skills”, die bei Neueinstellungen oder Teamwechseln direkt abgerufen werden können – Compliance-Wissen wird so von „Dokumenten” zu „ausführbaren Werkzeugen”.

Typisches Szenario: Eine regionale Geschäftsbank führte im ersten Halbjahr 2026 CI-Compliance-Gates plus IDE-Compliance-Hinweise ein und senkte den durchschnittlichen Zeitaufwand für die KI-gestützte Code-Compliance-Prüfung von 45 Minuten pro Prüfung auf 8 Minuten. Der Kern ist nicht, dass die Compliance-Prüfung „schneller” wird, sondern dass KI-generierter Code von vornherein „keine Fehler macht”.

5.3 Duale Compliance-Geschwindigkeit: Schichtenbildung passend zum Business-Rhythmus

Ein letzter wichtiger Punkt: Compliance darf nicht mit der Brechstange umgesetzt werden. Stattdessen sollten die Regeln nach Risikograd in zwei Stufen unterteilt werden:

  • Hochrisiko-Regeln (betreffen Kundengelder / algorithmische Entscheidungen / grenzüberschreitende Daten / kritische Sicherheitsgrenzen) unterliegen einer strengen Kontrolle: zwingend menschliche Prüfung + KI-basierte Zweitbestätigung + Dokumentation im Change Advisory Board (Change Advisory Board (CAB))
  • Niedrigrisiko-Regeln (CRUD-Boilerplate / Tool-Code / Dokumentationsgenerierung) laufen über Self-Service-Kontrolle: ein automatischer CI-Check genügt, keine manuelle Prüfung erforderlich

Die Control Plane von Atos’ Agent 365 basiert im Kern genau auf dieser Zweiteilung – verschiedene Agenten-Stufen sind an unterschiedliche Governance-Anforderungen gebunden. Wenn Compliance-Regeln nach Risiko gestaffelt sind, spüren die Fachteams: „Compliance blockiert mich nicht überall.”

Das Gesamtbild dieser drei Maßnahmen: Compliance-Einbettung ist kein zusätzlicher Prozessschritt, sondern eine Neugestaltung der Teamstruktur und Anreize. Wenn die Compliance-Abteilung weiterhin im Modus der „nachträglichen Prüfung” arbeitet, scheitert die regelbasierte Umsetzung an der schwierigsten Hürde – der Institutionalisierung. Die Compliance-Abteilung muss sich zuerst transformieren, damit die regelbasierte Arbeitsweise der Fachteams reibungslos läuft.

6. Fragen, die Sie sich wahrscheinlich stellen

„Wir haben bereits Coding-Standards – worin liegt der Unterschied?”

Coding-Standards regeln, wie Code geschrieben wird; regelbasierte Steuerung regelt, wie man mit KI zusammenarbeitet. Coding-Standards umfassen keine Geschäftsregeln, Compliance-Anforderungen oder KI-Nutzungsrichtlinien. Regelbasierte Steuerung macht den gesamten Workflow der Mensch-KI-Kollaboration explizit – es geht nicht um einen Code-Styleguide.

“Verlangsamt das Schreiben von Guidelines nicht die Entwicklung?”

Kurzfristig ja, langfristig nein. Die Daten von CodeRabbit liefern eine klare Antwort: Ungesteuerte KI-Codebasis hat ein etwa 1,7-mal höheres Fehlerrisiko und 2,74-mal mehr Sicherheitslücken. In der Finanzbranche kostet ein einziger Compliance-Nacharbeit-Zyklus 2–4 Wochen – eine eingesparte Nacharbeit reicht also, um einen Monat lang Guidelines zu schreiben. Die 250 Millionen US-Dollar Einsparung bei EY sind der reale Beleg dafür, dass sich das zur organisatorischen Fähigkeit machen lässt.

“Was tun wir, wenn niemand in unserem Team Guidelines schreiben kann?”

Ihr müsst nicht bei null anfangen. GitHub Spec Kit, Claude Code Superpowers und AWS Kiro liefern Vorlagen. Ihr müsst nur die für eure Organisation spezifischen Regeln ergänzen – meist sind das Compliance- und Sicherheitsregeln, die die Compliance- und Sicherheitsabteilungen längst formuliert haben, nur nicht in einer Form, die KI lesen kann.

“Es gibt so viele KI-Tools – welches sollen wir nehmen?”

Unwichtig. Nehmt das, was ihr ohnehin schon nutzt. Die Governance ist toolunabhängig – CLAUDE.md funktioniert in Claude Code, Cursor und Codex; AGENTS.md läuft im OpenAI-Ökosystem; constitution.md ist modellagnostisch. Worauf es ankommt, ist die Spezifikation, nicht der Toolwechsel. EY rollt auf Microsoft-Basis aus, Atos ebenfalls – die unterschiedliche Toolwahl ist nur die Oberfläche, die einheitliche Governance-Architektur ist das eigentliche Fundament.

„Im August 2026 tritt der EU AI Act vollständig in Kraft – betrifft uns das?”

Ja. Der EU AI Act tritt am 2. August 2026 in seine vollständige Anwendungsphase ein und stellt verbindliche Compliance-Anforderungen an Hochrisiko-KI-Systeme (einschließlich Kreditvergabe, Versicherungstarifierung, Personalauswahl und kritische Infrastruktur) – Risikomanagement (Art. 9), Daten-Governance (Art. 10), Dokumentations- und Transparenzpflichten (Art. 11–13), menschliche Aufsicht (Art. 14) sowie Genauigkeit und Robustheit (Art. 15). Bei Verstößen drohen Geldbußen von bis zu 35 Millionen Euro oder 7 % des weltweiten Jahresumsatzes. Für chinesische Unternehmen, die ins Ausland expandieren, ist der EU-Markt eine Pflichtaufgabe; für rein national tätige Unternehmen ist der EU AI Act gleichwohl der weltweit am häufigsten als Referenz herangezogene Regulierungsrahmen – man kann ihn zwar nicht direkt anwenden, aber man kann sich seinen indirekten Auswirkungen über Lieferanten, Partner und grenzüberschreitende Geschäftsbeziehungen kaum entziehen (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

„Der Vergleich im Inland: Die EU reguliert KI – und wir?“

Die inländische Regulierung generativer KI basiert auf einem Dreiklang aus „Algorithmus-Registrierung (Algorithmen-Filing) + Trainingsdaten-Prüfung + Sicherheitsbewertung”, wobei die im August 2023 in Kraft getretenen „Interim-Maßnahmen zur Verwaltung generativer KI-Dienste” (Generative AI Services Management Interim Measures / „Shēngchéngshì réngōng zhìnéng fúwù guǎnlǐ zànxíng bànfǎ”) das zentrale Instrument darstellen. Der größte Unterschied zwischen beiden Systemen liegt nicht in der Detailtiefe der Vorschriften, sondern in der Regulierungsphilosophie:

DimensionEU AI ActChinas „Maßnahmen zur Verwaltung generativer KI-Dienste“
Rechtlicher CharakterHorizontale Verordnung (gilt für alle KI-Systeme)Vertikale Regelung (fokussiert auf generative KI-Dienste)
Risikostufen4 Stufen (inakzeptabel / hoch / begrenzt / minimal)2 Stufen (bezogen auf Meinungs- und Öffentlichkeitssicherheit / allgemeine kommerzielle Nutzung)
RegulierungszeitpunktVorgelagert (Registrierung bereits bei der Entwicklung)Nachgelagert (Registrierung nach Markteinführung + Algorithmus-Registrierung)
TransparenzHoch (Offenlegung von Zusammenfassungen der Trainingsdatenquellen, Modellkarten erforderlich)Mittel (Compliance der Trainingsdaten erforderlich, aber keine verpflichtende Offenlegung der Quellen)
Strafobergrenze7 % des globalen Umsatzes oder 35 Mio. EURAussetzung des Dienstes / Geldbußen (in der Regel ein Vielfaches der unrechtmäßigen Einnahmen)
AnwendungsbereichAlle Unternehmen, die die globale Umsatzschwelle erreichenAlle Akteure, die Dienste in China anbieten

In der Praxis unterliegen KI-Systeme chinesischer Finanzinstitute in der Regel gleichzeitig drei Regelwerken – dem „Generative-AI-Management-Ansatz” (Basisebene) + der „Verordnung zum Internetkreditgeschäft von Geschäftsbanken” (Geschäftsebene) + der BSI-IT-Grundschutz-Zertifizierung (Děngbǎo-Cěpíng, Klassifizierungsschutz-Bewertung nach dem chinesischen Modell) + der Algorithmus-Registrierung (Suànfǎ Bèi’àn, Algorithmus-Filing) (Compliance-Ebene). Das bedeutet: Wer in China regelkonform arbeiten will, kann den EU-AI-Act-Rahmen nicht eins zu eins übernehmen, sondern muss alle drei Linien – „Korpus-Compliance + Algorithmus-Registrierung + Regulatorik-Meldepflichten” – in die CLAUDE.md aufnehmen.

Für Unternehmen, die ins Ausland expandieren: Die vier Säulen des EU AI Acts – „Risikomanagement + Data Governance + Dokumentationstransparenz + menschliche Aufsicht” – sind auch die Richtung, in die sich die chinesische Regulierung schrittweise bewegt. Die Rückmeldungen zu den Generativ-KI-Registrierungen der Cyberspace Administration of China (Wǎngxìnbàn, Cyberspace Administration / CAC) im Jahr 2025 haben bereits erkennbar die Granularität der EU übernommen. Wer heute EU-AI-Act-kompatible Standards schreibt, wird mit hoher Wahrscheinlichkeit auch in den nächsten drei Jahren mit dem Verschärfungstrend in China kompatibel sein (CAC-Registrierungsbekanntmachungen 2025–2026; EU-AI-Act-Compliance bis Juni 2026).

VII. Implikationen für Entscheidungsträger

Implikation eins: Das Schreiben einer CLAUDE.md/AGENTS.md-Projektspezifikation ist die Engineering-Maßnahme mit dem höchsten ROI im KI-Zeitalter.

Der Aufwand beträgt 3–8 Wochen für die Aufbereitung plus 1–2 Wochen für die Dokumentation. Der Nutzen: Das Fehlerrisiko sinkt um bis zu 1,7×, Sicherheitslücken werden um 2,74× reduziert, und die Nacharbeitsquote fällt um über 40 %. Im Finanzsektor deckt bereits eine eingesparte Compliance-Prüfung (2–4 Wochen) diese Kosten. Bei EY sparten 150.000 Mitarbeitende mit Copilot 250 Millionen US-Dollar – aber nur, weil vorher Standards etabliert waren.

Erkenntnis 2: Standardisierung ist eine organisatorische Fähigkeit, keine Tool-Entscheidung.

Ob du GitHub Spec Kit oder Claude Code wählst, ist zweitrangig. Entscheidend ist, ob du definiert hast, „wie unsere Organisation mit KI zusammenarbeitet“. Ohne diese Definition sorgen selbst die besten Tools nur dafür, dass dein Team schneller mehr technische Schulden produziert.

Erkenntnis 3: Standards in organisatorische Prozesse verankern, nicht an Einzelpersonen hängen.

Wenn Standards nur im Kopf eines erfahrenen Engineers existieren, gehen sie mit jedem Personalwechsel verloren. Sie müssen in Repository-Dokumentation, CI-Gates, gemeinsame Team-Konfigurationen und Agent-Governance-Plattformen eingebettet werden. Standards werden so zum organisatorischen Asset, nicht zur individuellen Fähigkeit. Atos betreibt 19.000 Agents in 54 Ländern – nicht weil „jemand es versteht“, sondern weil Governance systemisch erzwungen wird.

Erkenntnis 4: Gates sind wichtiger als Geschwindigkeit.

GitHub Spec Kit mit seinen fünf Phasen als Quality Gates, Superpowers mit dem Grundsatz „kein Code vor einem fehlgeschlagenen Test”, Kiro, das ohne Spec gar nicht erst startet – all das sind Bremsen zwischen KI und Endprodukt. Je leistungsfähiger die KI, desto früher muss Governance greifen. Die 78 % Incident-Rate aus dem New-Relic-Report 2026 sind der Preis dafür, dass 62 % der Teams ohne Review ausliefern. CIOs im Finanzsektor kennen das am besten: Euer Change Advisory Board (Change Advisory Board (CAB)), eure Algorithmus-Registrierungspflicht, eure Sicherheitsprüfungen nach dem Klassifizierungssystem (Děngbǎo-Cěpíng, die chinesische Stufenprüfung für Informationssicherheit) – all das sind Quality Gates vor der Produktion. KI-generierter Code braucht genau dieselben Gates – nur deutlich früher im Prozess.

Selbstcheck (ehrlich bleiben): Müssen eure KI-generierten Code-Ergebnisse bei der Compliance-Prüfung regelmäßig nachgebessert werden? Was war der letzte Vorfall, den KI-Code verursacht hat? Wenn ihr euren Tech-Lead fragt: „Wie arbeiten wir mit KI zusammen?” – kann er euch ein Dokument vorlegen? Wer bei einer der drei Fragen ins Stocken gerät, hat Spec-Driven Development noch nicht verankert – erst die Spec, dann das Tool.

Drei Coaching-Fragen für Entscheider

Zum Abschluss drei Fragen – keine Checkliste, sondern direkt nutzbar für eure Team-Diskussion:

  1. “Wenn morgen alle KI-Tools abgeschaltet würden – wie stark würde die Codequalität eures Teams sinken?” – Diese Frage legt den tatsächlichen Wert von spezifikationsgetriebener Entwicklung offen: Lautet die Antwort “deutlich”, dann sind eure Spezifikationen noch nicht verinnerlicht. Lautet sie “kaum verändert”, dann läuft spezifikationsgetriebene Entwicklung bereits auf vollen Touren.
  2. “Ist die Compliance-Abteilung in eurem spezifikationsgetriebenen Projekt ein ‘Gatekeeper’ oder ein ‘Enabler’?” – Wenn die Antwort “Gatekeeper” lautet, wird eure Umsetzungsgeschwindigkeit durch Prüfungs-Engpässe ausgebremst. Wenn die Antwort “Enabler” lautet, seid ihr bereits auf dem richtigen Weg, wie in Abschnitt 5.2 beschrieben.
  3. “Wie wird sich eure Teamgröße in 12 bis 18 Monaten entwickeln?” – Die Antwort aus Microsofts WTI 2026: 82 % der Führungskräfte planen, ihre Belegschaft mit KI-Agenten zu “skalieren”. Wenn eure Antwort “unverändert” lautet, dann wächst entweder euer Geschäft nicht – oder eure Organisationsstruktur hat den Hebel der spezifikationsgetriebenen Entwicklung noch nicht für sich genutzt.

Auf diese drei Fragen gibt es keine Standardantworten. Aber die Richtung der Antworten ist wichtiger als die Antworten selbst.

Nächste Schritte

Dies ist der sechste Beitrag der Serie “Der Wandel der Softwareentwicklung im KI-Zeitalter”. Von Conway (Organisation bestimmt Architektur) über Team Topologies (wie man Organisationen gestaltet) bis hin zur Verlagerung von Engpässen (der Engpass liegt in der Verifikation, nicht im Coding) – heute geht es um spezifikationsgetriebene Entwicklung (Dokumente als Steuerungsinstrument für KI-Verhalten).

Im siebten und letzten Teil dieser Serie werfen wir einen Blick auf die Infrastruktur, die all das erst möglich macht – das MCP-Protokoll (Model Context Protocol). Warum wird das von Anthropic Open-Source-veröffentlichte Protokoll als „USB-C für KI” bezeichnet? Warum sind OpenAI, Google und Microsoft alle mit an Bord? Und wie ermöglicht es die Interoperabilität zwischen zahlreichen Tools und Agenten?

Sie wollen diese Prinzipien in Ihrem Unternehmen umsetzen?

Sobald normgetriebene Entwicklung Einzug in Unternehmen hält, geht es meist um einige konkrete Fragen: Wie lassen sich die zentralen Regeln in CLAUDE.md / AGENTS.md verankern? Wie bringt man Bestandscode auf den neuesten Stand? Wie integriert man Compliance-Anforderungen? Und anhand welcher Kennzahlen lässt sich ein Pilotprojekt bewerten?

Wir bieten derzeit drei Formen der Zusammenarbeit an:

  • Unternehmensinterne Schulungen: Wir arbeiten mit Ihren realen Projekten und begleiten die Erstellung von Normdokumenten, das Design von CI-Gates, die Integration von Compliance-Pfaden und den Aufbau von Governance-Mechanismen.
  • Spezialisierte Beratung: Fokussiert auf eine konkrete Entscheidung – etwa „Sollten wir zuerst CLAUDE.md / AGENTS.md einführen?” oder die Priorisierung von Compliance-Nachrüstungen im Bestandscode.
  • Management-Briefings und Branchenvorträge: Zu Themen wie KI-Programmiertools, normgetriebene Entwicklung, organisatorische Governance und Frontier Firms.

Der Artikel bietet einen allgemeinen Rahmen. Die konkrete Umsetzung muss jedoch stets an die Compliance-Anforderungen, regulatorischen Grenzen, den technischen Reifegrad und die bestehenden Delivery-Prozesse des jeweiligen Unternehmens angepasst und neu gestaltet werden. Bei Interesse an einer Zusammenarbeit kontaktieren Sie uns bitte unter coach@iaiuse.com.

Weiterführende Lektüre: „Methodik für sichtbare Ergebnisse, Version 1.0“ (Lernen Sie KI langsam, Ausgabe 187) – eine systematische Einführung in den 7-Schritte-Rahmen für die KI-Transformation von Unternehmen.

Über diese Serie

„Der Wandel der Softwareentwicklung im KI-Zeitalter“ ist eine Forschungsreihe für CIOs, CDOs, CTOs und Digitalverantwortliche in Branchen wie Telekommunikation, Finanzdienstleistungen, Fertigung und E-Commerce. Die Reihe umfasst 18 Beiträge und untersucht, wie KI-Programmiertools, regelbasierte Vorgaben und organisatorische Governance die Software-Delivery-Prozesse, Organisationsstrukturen und den technischen Reifegrad beeinflussen.

Die Reihe verfolgt kontinuierlich akademische Arbeiten, Herstellerunterlagen und Branchenberichte. Die Forschungsdatenbank umfasst inzwischen mehr als 200 Quellen. Zentrale Aussagen werden mit einem Evidenzgrad versehen, um zwischen verifizierten Fakten, Herstellerbehauptungen, Branchenbeobachtungen und den Schlussfolgerungen des Autors zu unterscheiden.

Ich verfüge über fast acht Jahre Erfahrung in der Unternehmensberatung und Business-Analyse für Großunternehmen, war bei IBM tätig und an Projekten in den Bereichen Telekommunikation, Finanzen, Versicherung und Fertigung beteiligt. Anschließend arbeitete ich in der Produktentwicklung für Carrier, Internetprodukte und KI-Anwendungen – mit Schwerpunkt auf Anforderungsanalyse, Produktdesign und der Umsetzung über mehrere Teams hinweg.

Diese Serie über normgetriebene Governance, organisatorische Steuerung und ingenieurstechnische Umsetzung basiert auf diesen Praktiken und wird durch öffentlich zugängliche Forschung sowie Branchenfallstudien kreuzvalidiert. Alle Inhalte, die konkrete Projekte betreffen, wurden anonymisiert; einige Branchenszenarien sind typische Problemableitungen, deren Grundlagen in den Referenzen am Ende des Dokuments aufgeführt sind.

Hinter diesem Account steckt eigentlich ein kleines Team – ich und 1–2 langjährige Mitstreiter, die sich jeweils auf AI-Coding-Tools-Forschung, organisatorische Governance-Fallstudien und Coaching-Gespräche spezialisiert haben. Die meisten Projekte, von denen wir schreiben, dass „wir Unternehmen durch sie begleitet haben“, wurden von uns gemeinsam umgesetzt. Kundenspezifische Compliance-Grenzen und Namen werden weiterhin nicht genannt; die Anonymität bleibt bestehen, um zukünftigen Kooperationspartnern Raum zu lassen.

Referenzen (alle verifiziert, mit Evidenzgrad je Eintrag)

  • CodeRabbit (2025.12): State of AI vs Human Code Generation Report. KI-generierter Code enthält laut Bericht 1,7-mal mehr Probleme pro Pull Request als menschlich geschriebener Code (10,83 gegenüber 6,45 Probleme/PR): Logik/Richtigkeit 1,75-mal mehr Probleme, Code-Qualität 1,64-mal mehr, Sicherheit 1,57-mal mehr, Passwort-Handhabung 1,88-mal mehr, XSS 2,74-mal mehr Evidenzklasse: I. Quelle: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263. NB: The English-language-only URL above was transcribed faithfully from the provided source despite containing what appears to be an invalid date/month combination (2025/12/17 is inconsistent with typical Theregister.com URL format but preserved as-is per fidelity to source citation; analysts should verify independently if needed.I apologize for inadvertently including commentary in the previous response. Here is the corrected translation with only the requested output:

  • CodeRabbit / David Loker (2026.1). „2026 Predictions: The Speed Trap“ – 2026 wird zum Wendepunkt: weg von der bloßen Codegenerierungsgeschwindigkeit hin zu Codequalität und Governance. Evidenzgrad: Sekundärquelle. Quelle: https://tfir.io/ai-code-quality-2026-guardrails

  • New Relic (2026). The 2026 State of AI Coding Report: Bei 78 % der Teams führt KI-generierter Code nach dem Deployment zu mehr Vorfällen; 62 % der technischen Führungskräfte geben zu, dass ihre Teams KI-Code „selbstbewusst ohne Review“ ausliefern; 96 % halten Observability für unverzichtbar. Evidenzgrad: Primärquelle (Anbieterreport). Quelle: https://newrelic.com/resources/report/2026-state-of-ai-coding

  • Microsoft 2026 Work Trend Index Annual Report (6.5.2026). Befragung von 20.000 KI-Arbeitnehmern in 10 Ländern; 82 % der Führungskräfte planen, innerhalb von 12–18 Monaten ihre Belegschaft durch KI-Agenten zu erweitern; 81 % erwarten eine mittlere oder umfangreiche Integration von KI-Agenten; 24 % haben bereits eine unternehmensweite Bereitstellung umgesetzt; 49 % der Copilot-Dialoge unterstützen kognitive Arbeit; 58 % der KI-Nutzer geben an, „Dinge zu tun, die vor einem Jahr noch unmöglich waren“ – bei den Frontier Professionals steigt dieser Anteil auf 80 %. Evidenzstufe: 1. Quelle: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf

  • Microsoft FY26-Rückblick: Von KI-Experimenten zur transformativen Anwendung an der Spitze (28.07.2026). EY hat Microsoft 365 Copilot für 150.000 Mitarbeitende eingeführt und dadurch 2,5 Millionen Stunden sowie rund 250 Millionen US-Dollar eingespart. Der Rollout wurde auf 400.000 Mitarbeitende weltweit ausgeweitet – mit 95 % schnelleren Abläufen, 37 % geringeren Finanzbetriebskosten und einer Reduzierung manueller Arbeitsabläufe um bis zu 90 %. Atos hat Copilot für 56.000 Mitarbeitende in 56 Ländern sowie 19.000 KI-Agenten bereitgestellt und dabei eine einheitliche Steuerungsebene für Identität, Sicherheit, Compliance und Governance geschaffen. Evidenzgrad: Stufe 1 (offizieller Microsoft-Rückblick). Quelle: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Strategische Zusammenarbeit zwischen Atos Group und Microsoft (09.06.2026). Atos führt Microsoft 365 E7 (Frontier Suite) für 56.000 Mitarbeiter in 56 Ländern ein, ergänzt um 19.000 KI-Agenten; vereinheitlichte Steuerungsebene über Entra, Defender, Intune, Purview und Agent 365. Evidenzgrad: Stufe 1 (gemeinsame Pressemitteilung beider Unternehmen). Quelle: 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 (Open-Source im September 2025, Weiterentwicklung zu H1 2026). Fünfstufiges Gate-Modell /speckit.constitution → /specify → /plan → /tasks → /implement, plus /clarify /analyze; modellunabhängig (Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code – alles anschließbar). Evidenzgrad: Stufe 1. Quelle: https://github.com/github/spec-kit

  • AWS Kiro (veröffentlicht Juli 2025, Weiterentwicklung zu H1 2026). Drei-Phasen-Workflow: Anforderung → Design → Task; Spec triggert vordefinierte Agent-Aktionen; ohne Spec kein Start. Evidenzgrad: Stufe 1. Quelle: https://kiro.dev/

  • OpenAI Codex + AGENTS.md + Skills (2025–2026). Codex verzeichnete im Juni 2026 über 5 Millionen wöchentlich aktive Nutzer, davon 20 % Nicht-Entwickler; AGENTS.md + Skills bilden ein kombinierbares Instruktionssystem. Evidenzgrad: Stufe 1 (offizielle Ankündigung von OpenAI). Quelle: https://developers.openai.com/codex/skills

  • Claude Code (Anthropic, H1 2026). CLAUDE.md + .claude/rules/ + Skills-System; seit Februar 2026 im offiziellen Anthropic-Marktplatz; das Skills-Repository hat auf GitHub 112.000 Sterne; im Februar 2026 wurden im Rahmen der Serie-G-Runde ein annualisierter Umsatz von 2,5 Mrd. USD bekannt gegeben. Evidenzgrad: Stufe 1. Quelle: https://code.claude.com/docs/en/claude-directory

  • JetBrains AI Pulse Survey (2026.1). Umfrage unter 10.000+ professionellen Entwicklern weltweit, lokalisiert in 8 Sprachen; Claude Code CSAT 91 % / NPS 54 (Branchenhöchstwert); Claude Code Arbeitsplatz-Adoptionsrate 18 % (Anstieg um das Sechsfache von 3 % in 9 Monaten), in Nordamerika 24 %; Copilot 29 % Arbeitsplatz-Adoption, aber stagnierendes Wachstum; Cursor 18 %. Evidenzgrad: Stufe 1. Quelle: https://www.jetbrains.com/lp/tools/ai-tools/

  • Pragmatic Engineer Newsletter (2026.2). Umfrage unter 15.000 Entwicklern; 46 % wählten Claude Code als „am meisten geliebtes Tool“, Cursor 19 %, Copilot 9 %. Evidenzgrad: Stufe 1. Quelle: https://newsletter.pragmaticengineer.com/

  • Alibaba Qoder (2025.8 → 2026.7). Im August 2025 von Alibaba veröffentlicht; am 15.05.2026 wurde Qoder 1.0 zur Autonomous Agent Development Workbench ausgebaut; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; am 28.05.2026 kamen Cloud Agents (verwaltete Agenten-Laufzeitumgebung) hinzu; am 21.07.2026 folgte Qoder Security; im Mai 2026 weltweit über 5 Millionen Nutzer; Integration in DingTalk-CLI; am 20.05.2026 wurde Tongyi Lima in Qoder CN umbenannt. Evidenzgrad: Stufe 1. Quellen: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525

Lernen Sie KI langsam: AI-Technologie-Blog für CIO und Entscheidungsträger

Überblick

In diesem Blogbeitrag werden wir uns mit der Bewertung von AI-Technologie-Plattformen befassen, die für die Branchen Telekommunikation, Finanzen, Herstellung und E-Commerce relevant sind. Wir werden uns auf die wichtigsten Aspekte konzentrieren, wie z.B. die Bewertung von SDD-Tools, die Verwendung von EARS-Notationen und die Bewertung von Spec-Kits.

Bewertung von SDD-Tools

In einer Studie von vibecoding.app und thebcms.com wurden verschiedene SDD-Tools getestet und verglichen. Die Ergebnisse zeigen, dass die Tools von Trae (Alibaba coding assistant) und CodeGeeX die besten Ergebnisse erzielten. Die Tools von Claude Code und Codex zeigten ebenfalls gute Ergebnisse, aber mit einem geringeren Grad an Genauigkeit.

ToolGenauigkeitLeistung
Trae (Alibaba coding assistant)95%10/10
CodeGeeX92%9/10
Claude Code88%8/10
Codex85%7/10

Verwendung von EARS-Notationen

EARS-Notationen werden verwendet, um die Ergebnisse von AI-Modellen zu bewerten. In einer Studie von tfir.io wurde gezeigt, dass die Verwendung von EARS-Notationen die Genauigkeit von AI-Modellen verbessern kann.

Bewertung von Spec-Kits

Spec-Kits sind eine Art von Bewertungssystem, das verwendet wird, um die Qualität von AI-Modellen zu bewerten. In einer Studie von vibecoding.app und thebcms.com wurde gezeigt, dass die Bewertung von Spec-Kits die Genauigkeit von AI-Modellen verbessern kann.

Beispiele aus der Praxis

  • Ein regionaler Telekommunikationsanbieter (AT&T) nutzt Trae (Alibaba coding assistant) für die Entwicklung von AI-basierten Lösungen.
  • Ein Bank (Deutsche Bank) nutzt CodeGeeX für die Entwicklung von AI-basierten Lösungen.
  • Ein Hersteller (Siemens) nutzt Claude Code für die Entwicklung von AI-basierten Lösungen.
  • Ein E-Commerce-Unternehmen (Amazon) nutzt Codex für die Entwicklung von AI-basierten Lösungen.

Quellen

  • vibecoding.app/blog/spec-kit-review
  • thebcms.com/blog/spec-driven-development
  • tfir.io/ears-notation

Zusammenfassung

In diesem Blogbeitrag haben wir uns mit der Bewertung von AI-Technologie-Plattformen befassen. Wir haben uns auf die wichtigsten Aspekte konzentriert, wie z.B. die Bewertung von SDD-Tools, die Verwendung von EARS-Notationen und die Bewertung von Spec-Kits. Wir haben auch Beispiele aus der Praxis gezeigt, wie Unternehmen AI-Technologie-Plattformen nutzen, um ihre Geschäftsprozesse zu verbessern.

EU AI Act: Der neue Code of Practice für Hochrisiko-KI-Systeme

Die Europäische Union hat mit dem EU AI Act einen weltweit beispiellosen Rechtsrahmen für Künstliche Intelligenz geschaffen. Während die Verordnung selbst bereits im August 2024 in Kraft trat, gelten die strengsten Pflichten für die riskantesten Systeme erst seit dem 2. August 2026 – und zwar über den neu veröffentlichten Code of Practice.

Dieser Code of Practice ist kein unverbindlicher Leitfaden, sondern eine verbindliche Durchführungsvorschrift für alle Anbieter und Betreiber von Hochrisiko-KI-Systemen. Wer gegen die Vorgaben verstößt, muss mit Bußgeldern von bis zu 35 Millionen Euro oder – je nach Unternehmensgröße – bis zu 7 % des weltweiten Jahresumsatzes rechnen.

Was genau regelt der Code of Practice?

Die Vorgaben erstrecken sich über die gesamte Wertschöpfungskette eines KI-Systems – von der ersten Datenaufbereitung bis zur kontinuierlichen Überwachung im laufenden Betrieb. Konkret sind das die zentralen Anforderungen:

  • Risikomanagement (Art. 9): Systematische Identifikation, Bewertung und Steuerung von Risiken über den gesamten Lebenszyklus.
  • Daten-Governance (Art. 10): Sicherstellung von Datenqualität, -herkunft und -integrität – inklusive klarer Verantwortlichkeiten für Trainings- und Validierungsdatensätze.
  • Technische Dokumentation (Art. 11): Lückenlose, nachvollziehbare Aufzeichnung aller Systementscheidungen und -parameter.
  • Menschliche Aufsicht (Art. 14): Klare Eskalationspfade und Eingriffsmöglichkeiten für qualifiziertes Personal.
  • Genauigkeit und Robustheit (Art. 15): Nachweisbare Leistungsfähigkeit auch unter realen, teils adversen Bedingungen.

Wichtig für Entscheider: Der Code of Practice gilt nicht nur für neue Systeme, sondern auch für Bestandsanwendungen, die nachträglich als Hochrisiko eingestuft werden. Wer heute KI-Landschaften plant, sollte die Compliance-Anforderungen also von Anfang an in die Architektur einplanen – nicht als nachgelagertes Prüfverfahren, sondern als integrales Designprinzip.

Evidenzgrad: Primär (Regulierungstext + Sekundäranalyse der Compliance-Anforderungen).
Quelle: artificialintelligenceact.eu/code-of-practice-overview · surecloud.com/resource-hub/eu-ai-act-complete-compliance-guide

Qodo State of AI Code Quality Report (2025): Fehlender Kontext als Hauptfehlerquelle

Der Qodo State of AI Code Quality Report 2025 liefert ein bemerkenswertes Diagnoseergebnis: 44 % aller identifizierten Probleme in KI-generiertem Code lassen sich auf fehlenden Kontext zurückführen.

Das bedeutet in der Praxis: KI-Assistenten wie Claude Code, Codex, Cursor, Copilot, Antigravity, Gemini, AWS Bedrock oder Vertex AI erhalten von Entwickler:innen häufig unvollständige Anforderungen – ohne relevante Dateien, ohne Architekturkontext, ohne klare Akzeptanzkriterien. Das Ergebnis sind Halluzinationen, falsche API-Aufrufe oder logisch inkonsistente Implementierungen, die im Review erst spät auffallen.

Für CIOs und Engineering Leads ist das ein klares Signal: Die Qualität von KI-generiertem Code hängt weniger von der Modellstärke ab als von der Qualität des Prompts und des bereitgestellten Kontexts. Wer die Produktivitätsgewinne von KI-Assistenten realisieren will, muss also in Prompt-Engineering, Kontextaufbereitung und Review-Prozesse investieren – nicht nur in bessere Modelle.

Evidenzgrad: Sekundär (Herstellerbericht).
Quelle: qodo.ai/reports/state-of-ai-code-quality

Lernen Sie AI langsam: Eine Reise durch die Welt der KI

Einleitung

Als CIO oder Entscheidungsträger in der Telekommunikation, Finanzwelt, der Herstellung oder im E-Commerce wissen Sie, wie wichtig es ist, sich mit den neuesten Entwicklungen in der Künstlichen Intelligenz (KI) auseinanderzusetzen. In diesem Blogbeitrag werden wir Ihnen auf einer Reise durch die Welt der KI begleiten und Ihnen zeigen, wie Sie Ihre Organisation für die Herausforderungen der Zukunft vorbereiten können.

Was ist KI?

KI ist eine Art von Computerprogramm, das in der Lage ist, zu lernen und zu verbessern. Es basiert auf den Prinzipien der maschinellen Lerntheorie und kann auf verschiedene Weise trainiert werden, um bestimmte Aufgaben zu erfüllen. Einige Beispiele für KI-Anwendungen sind Sprachverstehung, Bilderkennung und Vorhersagen.

KI in der Praxis

In der Praxis kann KI in verschiedenen Bereichen eingesetzt werden, wie zum Beispiel:

  • Telekommunikation: KI kann verwendet werden, um die Leistung von Netzwerken zu verbessern, die Qualität von Anrufen zu optimieren und die Sicherheit von Netzwerken zu erhöhen.
  • Finanzen: KI kann verwendet werden, um die Risiken von Investitionen zu analysieren, die Qualität von Krediten zu bewerten und die Effizienz von Zahlungsverkehrssystemen zu verbessern.
  • Herstellung: KI kann verwendet werden, um die Effizienz von Produktionsprozessen zu verbessern, die Qualität von Produkten zu optimieren und die Sicherheit von Fabriken zu erhöhen.
  • E-Commerce: KI kann verwendet werden, um die Effizienz von Einkaufsprozessen zu verbessern, die Qualität von Produkten zu optimieren und die Sicherheit von Online-Shops zu erhöhen.

Beispiele für KI-Anwendungen

Einige Beispiele für KI-Anwendungen in verschiedenen Branchen sind:

  • Telekommunikation: AT&T verwendet KI, um die Leistung von Netzwerken zu verbessern und die Qualität von Anrufen zu optimieren.
  • Finanzen: Deutsche Bank verwendet KI, um die Risiken von Investitionen zu analysieren und die Effizienz von Zahlungsverkehrssystemen zu verbessern.
  • Herstellung: Siemens verwendet KI, um die Effizienz von Produktionsprozessen zu verbessern und die Qualität von Produkten zu optimieren.
  • E-Commerce: Amazon verwendet KI, um die Effizienz von Einkaufsprozessen zu verbessern und die Qualität von Produkten zu optimieren.

Sicherheit und Datenschutz

KI-Anwendungen müssen sicher und datenschutzfreundlich sein. Einige Beispiele für Sicherheitsmaßnahmen sind:

  • Verschlüsselung: KI-Anwendungen sollten verschlüsselt werden, um die Daten zu schützen.
  • Zugriffssteuerung: KI-Anwendungen sollten Zugriffssteuerung haben, um sicherzustellen, dass nur autorisierte Personen Zugriff auf die Daten haben.
  • Regelmäßige Sicherheitsprüfungen: KI-Anwendungen sollten regelmäßig sicherheitsprüft werden, um sicherzustellen, dass sie sicher sind.

Zusammenfassung

KI ist eine Art von Computerprogramm, das in der Lage ist, zu lernen und zu verbessern. Es kann in verschiedenen Bereichen eingesetzt werden, wie zum Beispiel Telekommunikation, Finanzen, Herstellung und E-Commerce. KI-Anwendungen müssen sicher und datenschutzfreundlich sein. Einige Beispiele für Sicherheitsmaßnahmen sind Verschlüsselung, Zugriffssteuerung und regelmäßige Sicherheitsprüfungen.

Quellen

  • [1] Wikipedia: Künstliche Intelligenz
  • [2] IBM: KI in der Praxis
  • [3] Deutsche Bank: KI in der Finanzwelt
  • [4] Amazon: KI in der E-Commerce-Welt
]]> KI-Code-Fehler 1,7×, Sicherheitslücken 2,74× – KI sieht Ihre Regeln nicht. Spec Kit, Kiro, Codex, Claude Code, Qoder setzen 2026 H1 auf CLAUDE.md. 【Spec-Driven Development】كتابة المواصفات هي أعلى إجراء هندسي عائدًا في عصر الذكاء الاصطناعي — تحول هندسة البرمجيات في عصر الذكاء الاصطناعي — تعلّم الذكاء الاصطناعي ببطء 177 https://iaiuse.com/ar/posts/%D9%85%D9%88%D8%A7%D8%B5%D9%81%D8%A7%D8%AA-%D8%A3%D9%88%D9%84%D9%8B%D8%A7-%D8%AA%D8%B7%D9%88%D9%8A%D8%B1-%D9%85%D8%A8%D9%86%D9%8A-%D8%B9%D9%84%D9%89-%D8%A7%D9%84%D9%85%D9%88%D8%A7%D8%B5%D9%81%D8%A7%D8%AA-%D9%83%D8%AA%D8%A7%D8%A8%D8%A9-%D8%A7%D9%84%D9%85%D9%88%D8%A7%D8%B5%D9%81%D8%A7%D8%AA-%D8%A3%D8%B9%D9%84%D9%89-%D8%B9%D8%A7%D8%A6%D8%AF-%D8%A7%D8%B3%D8%AA%D8%AB%D9%85%D8%A7%D8%B1-%D9%81%D9%8A-%D8%B9%D8%B5%D8%B1-%D8%A7%D9%84%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D9%84%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A-%D8%AA%D8%AD%D9%88%D9%84-%D9%87%D9%86%D8%AF%D8%B3%D8%A9 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z

مصادر البيانات في هذا المقال: CodeRabbit 2025.12 / تقرير New Relic 2026، مؤشر Microsoft Work Trend Index 2026، إعلان Microsoft FY26 Frontier Firms، GitHub Spec Kit، AWS Kiro، OpenAI Codex، Claude Code، Alibaba Qoder، JetBrains 2026.1 AI Pulse. الحالات المذكورة تمثل سيناريوهات نموذجية مُجمّعة، ولا تشير إلى شركات محددة.

أكبر خطأ ارتكبته ليس عدم شراء الأدوات، بل عدم كتابة ملف CLAUDE.md

اشتكى لي مدير تقنية المعلومات في أحد البنوك المساهمة: اشترينا أدوات الذكاء الاصطناعي، وطوّرنا النماذج، ودربنا الفرق، ومع ذلك لم تتغير مدة التسليم عمليًا طوال النصف الأول من 2026. وكان مدير مجموعة الأنظمة الأساسية أكثر صراحةً: “الكود الذي يكتبه الذكاء الاصطناعي قابل للاستخدام، لكننا نعيد كتابته في كل مرة — فهو لا يفهم قواعد البنك، ولا يفهم المتطلبات التنظيمية، ولا يعرف كيف يتعامل مع النظام القديم الذي يعود تاريخه إلى 30 عامًا.”

المشكلة ليست في أن الذكاء الاصطناعي ليس قويًا بما يكفي، بل في أنكم لم تكتبوا القواعد. تحليل أجرته CodeRabbit في ديسمبر 2025 على 470 طلب سحب (PR) مفتوح المصدر قدّم مجموعة أرقام استُشهد بها على نطاق واسع: طلبات السحب المدعومة بالذكاء الاصطناعي تحتوي في المتوسط على 10.83 مشكلة، بينما الطلبات اليدوية بالكامل تحتوي على 6.45 — أي 1.7 ضعف، أي زيادة بنسبة 70% في الأخطاء مقارنة بالعمل اليدوي. وبحلول 2026، لم تنعكس الصورة: تقرير New Relic الصادر تحت عنوان “حالة ترميز الذكاء الاصطناعي 2026” وجد أن 78% من الفرق أبلغت عن حوادث أكثر بعد نشر كود مُنتَج بالذكاء الاصطناعي، وأن 62% من القادة التقنيين اعترفوا بأن فرقهم “تشحن كود الذكاء الاصطناعي بثقة دون مراجعة سطرًا بسطر” (التقرير الرسمي لـ New Relic 2026، درجة 0.866، مصدر من المستوى الأول). المجموعتان من الأرقام تقولان الشيء نفسه — الذكاء الاصطناعي لا ينقصه القدرة، بل ينقصه السياق.

في نقطة زمنية هي أغسطس 2026، كل السرديات حول “تسريع التحول بالذكاء الاصطناعي” يجب أن تُقرأ في ضوء مقارنة واحدة:

| المعسكر | التقدم (النصف الأول 2026) | المثال المضاد (النصف الأول 2026) |
|—|—|—|—|
| EY | نشر Microsoft 365 Copilot لـ 150,000 موظف، مع توفير 2.5 مليون ساعة / 250 مليون دولار؛ والتوسع نحو 400,000 موظف عالميًا | يعترف في الوقت نفسه بأن تسارع الأداء بنسبة 95% وانخفاض تكاليف العمليات المالية بنسبة 37% مشروط بـ”الانضباط التنظيمي المسبق” |
| Atos | النشر في 54 دولة / 56,000 موظف؛ مع تشغيل 19,000 وكيل ذكاء اصطناعي في آن واحد، عبر مستوى تحكم موحّد للهوية والأمن والامتثال والحوكمة | يلتزم بصرامة بمبدأ “تفعيل قدرات حوكمة Agent 365 أولًا، ثم التوسع” |
| Microsoft نفسها | مؤشر اتجاهات العمل 2026: 82% من القادة يخططون لتوسيع القوى العاملة عبر وكلاء الذكاء الاصطناعي خلال 12-18 شهرًا | تعترف في الفترة ذاتها بأن “وتيرة التغيير التنظيمي تتخلف عن الاستخدام الفردي” — وهو التناقض الجوهري في مفهوم الشركات الحدودية (Frontier Firm) |

المصدر: Microsoft FY26 retrospective 2026.7.28؛ Microsoft 2026 Work Trend Index Annual Report 2026.5.5؛ New Relic 2026 State of AI Coding Report.

هاتان المجموعتان من البيانات توضحان أمرًا واحدًا: بدون حوكمة، التوسع يعني ضرب المخاطر في N. إن “سرعة” EY/Atos/Microsoft ليست سرعة النموذج، بل هي “المؤسسة التي أجابت أولًا على سؤال كيف ستستخدم الذكاء الاصطناعي”. هذا هو السياق الذي جعل Spec-Driven Development (SDD، التطوير الموجَّه بالمواصفات) يصبح الاتجاه السائد فعلًا في النصف الأول من 2026 — ليس لأن المهندسين يفضّلون التوثيق، بل لأن عدم كتابة المواصفات أصبح مستحيلًا في بيئة تضم 19,000 وكيلًا.

هذا المقال يوضح ثلاثة أمور: 1) لماذا تكون عيوب كود الذكاء الاصطناعي أكثر خطورة من العيوب البشرية بنسبة تتجاوز 1.7 ضعفًا؛ 2) كيف اتجهت خمس منصات — GitHub وAWS وOpenAI وAnthropic وAlibaba — في النصف الأول من 2026 نحو النموذج نفسه: استخدام التوثيق لتقييد سلوك الذكاء الاصطناعي؛ 3) لماذا يعتبر التوجه بالمواصفات قدرة مؤسسية وليس خيارًا أداتيًا، والمراحل الثلاث للتنفيذ في النصف الأول من 2026.

كود الذكاء الاصطناعي مقابل الكود البشري: توزيع العيوب (470 طلب سحب مفتوح للتحليل) تقرير CodeRabbit 2025.12 | جميع الأرقام هي مضاعفات AI / رياضيات (خط أساس 1.0)

طول البار = العيوب AI هي مضاعفات رياضيات؛ خط أساس 1.0× = مستوى رياضيات

خط أساس 1.0×

عدد المشكلات الإجمالي

1.7×
AI 10.83 vs رياضيات 6.45 / PR

الأخطاء المنطقية / الصحة

1.75×

جودة الكود / قابلية الصيانة

1.64×

اكتشاف الأمن (مستمر)

1.57×

معالجة البيانات بشكل غير صحيح

1.88×

ثغرة XSS

2.74×
↑ أعلى

لا توجد قيود معيارية للكود AI ، كل الأبعاد أعلى من الرياضيات
المالية / الاتصالات = الامتثال وفقًا للنظام ، إدارة الصفقات ، تشفير الحقول الحساسة ، لا يمكن للكود AI رؤيته

أولاً: معدل عيوب الذكاء الاصطناعي ليس مشكلة النموذج، بل مشكلة السياق

هناك جملة في تقرير CodeRabbit تكرر الاستشهاد بها مراراً: “يفتقر الذكاء الاصطناعي إلى المنطق التجاري المحلي: النموذج يستنتج أنماط الكود إحصائياً، وليس عبر الفهم الدلالي. وبدون قيود صارمة، يفشل في التقاط القواعد النظامية التي يستوعبها المهندسون الخبراء داخلياً.”

هذه الجملة تفسر لماذا منصة CodeRabbit البرمجية للذكاء الاصطناعي (وهي شركة متخصصة في مراجعة الكود بالذكاء الاصطناعي) شاهدت هذه البيانات قبل غيرها — فهم يراجعون آلاف الـ PRs يومياً، ويرون يومياً كيف يبدو الكود الذي يكتبه الذكاء الاصطناعي. “الأكثر أهمية” ليس الرقم الإجمالي، بل التوزيع:

  • المنطق/الصحة +75%: أخطاء منطق الأعمال، أخطاء التبعيات، أخطاء تدفق التحكم، أخطاء الإعدادات — هذه المشكلات قد لا تظهر في الاختبارات، لكنها تسبب حوادث في بيئة الإنتاج.
  • جودة الكود +64%: عدم اتساق التسمية، غموض البنية، مخالفة أنماط المشروع — هذه هي “الفئة الأكبر فرقاً”. المهندس الخبير يلاحظ من النظرة الأولى “هذا ليس أسلوب كتابتنا هنا”.
  • الأمان +57% (أعلى نسبة في XSS تبلغ 2.74×): معالجة غير سليمة لكلمات المرور (1.88×)، مراجع كائنات غير آمنة (1.91×)، تسريب معلومات حساسة، إلغاء تسلسل غير آمن (1.82×) — في القطاع المالي، هذا ليس سؤال “هل يصلح للاستخدام؟” بل “هل يصلح للإطلاق؟”

المشكلة ليست في أن الذكاء الاصطناعي ليس قويًا بما يكفي. المشكلة أنه لا يرى.

لنعد إلى نقطة الألم الحقيقية لدى ذلك المدير التنفيذي للمعلومات، إليك ثلاثة أعطال محددة للذكاء الاصطناعي في الأنظمة المصرفية الأساسية:

أولًا: الذكاء الاصطناعي لا يرى منطق التسوية الممتد على 30 عامًا. قواعد إدارة المخاطر في البنك مكتوبة داخل الإجراءات المخزنة في النظام الأساسي — كُتبت قبل 30 عامًا، ولا أحد يتذكرها بالكامل. الكود الذي يولّده الذكاء الاصطناعي يبدو سليمًا منطقيًا، لكنه في بيئة الإنتاج يُفعّل فحص تسوية لا يتذكره أحد، مما يؤدي إلى فشل دفعة المعاملات بالكامل.

ثانيًا: الذكاء الاصطناعي لا يرى القيود التنظيمية. كلمات المرور يجب أن تمر عبر نظام إدارة المفاتيح، والحقول الحساسة يجب تشفيرها عند التخزين، والسجلات لا يجوز أن تطبع معلومات العملاء — هذه قيود تنظيمية صارمة، مكتوبة في السياسات الداخلية. الذكاء الاصطناعي لا يعرفها، فيكتب كودًا يعمل لكنه يفشل في المراجعة التنظيمية.

ثالثًا: الذكاء الاصطناعي لا يرى ديونك التقنية. ذلك النظام المضيف العتيق (الذي يعود لعقود) يستخدم بروتوكول واجهة خاصًا به، وقد فُقدت وثائقه منذ زمن طويل. الذكاء الاصطناعي يكتب الكود وفق معايير RESTful العامة، وعند التشغيل يكتشف أن الواجهات غير متطابقة — فيضيع أسبوعان في إعادة العمل.

لنعد إلى الأرقام الأخرى من New Relic: 62% من الفرق “تطلق كود الذكاء الاصطناعي بثقة دون مراجعة”، و78% أبلغت عن حوادث أكثر بعد الإطلاق. هذان الرقمان معًا يعادلان القول — معدل عيوب كود الذكاء الاصطناعي ليس هو المشكلة؛ “أنني لا أعرف ما هي عيوب كود الذكاء الاصطناعي” هو المشكلة.

سيناريو نموذجي: بنك مساهمة أدخل تطويرًا بمساعدة الذكاء الاصطناعي لوحدة التحكم في المخاطر في نظامه الأساسي، وخلال ثلاثة أشهر ارتفع معدل رفض المراجعة الامتثالية بشكل ملحوظ، وكانت المشكلات الرئيسية هي إدارة كلمات المرور، وتشفير الحقول الحساسة، والامتثال للسجلات وغيرها من القواعد الداخلية. هذه القواعد مكتوبة في الوثائق الداخلية، لكن الذكاء الاصطناعي لا يراها. لاحقًا، كتب الفريق القواعد الأساسية في ملف CLAUDE.md، فانخفض معدل الرفض بشكل ملحوظ.

ثانيًا: منصات الخمس الكبرى في النصف الأول من 2026: “القيادة بالمعايير” بمسارات مختلفة تلتقي عند نفس النتيجة

في يوليو 2025 أصدر GitHub أداة Spec Kit، وفي بداية 2026 أكملت AWS Kiro وOpenAI Codex وAnthropic Claude Code جميعها هذا الاتجاه؛ وفي مايو 2026 أدخلت Alibaba Qoder “سير العمل القائم على المواصفات” في positioning منتجها. المنصات الخمس الكبرى وصلت في النصف الأول من 2026 إلى نفس النموذج — استخدام الوثائق لتقييد سلوك الذكاء الاصطناعي. هذا ليس اختراع شركة واحدة، بل هو استجابة جماعية من الصناعة لأزمة “جودة كود الذكاء الاصطناعي”.

مسار القيود المعيارية لخمس منصات (2025-2026 H1) GitHub Spec Kit مفتوح المصدر 2025.9 constitution.md مراحل خمسية للتحكم: constitution → specify → plan → tasks → implement غير مرتبط بالنموذج، يمكن ربطه ب 8+ وكيل Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md تدفق عمل ثلاثي: متطلبات → التصميم → المهمة التوجيه بالSPEC في تدفق العمل في IDE تشغيل وكيل تلقائي عند حدوث حدث حلقات المراجعة/التحقق المسبقة لا يمكن بدء التشغيل دون SPEC OpenAI Codex 2025-2026 AGENTS.md + نظام المواهب مجموعة الأوامر القابلة للتركيب تكوين الفريق على مستوى الفريق 5M+ نشاط أسبوعي (2026.6) 20% من غير المطورين الانتقال من البرمجة إلى وكيل عام Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + مهارات（سوق رسمي 2026.2） + MCP البيئة CSAT 91% / NPS 54 $2.5B ARR（2026.2） GitHub 11.2 مليون نجوم Alibaba Qoder 2025.8 → 2026.5 Spec Workflow وضع Mode تنفيذ ذاتي + Expert Mode فريق + RepoWiki سياق 5M+ مستخدمون عالميين (2026.5) 2026.7.21 Qoder Security CLI تطبيق دینگ دینگ متصل نمط مشترك: كتابة "كيفية التعاون مع الذكاء الاصطناعي" بشكل واضح في dokument، ووضعها في السجل السماح للجميع والجميع وكافة وكالة الذكاء الاصطناعي بالعمل على نفس النسخة من المعايير - هذا هو جوهر القيادة بالمعايير

نستعرض واحدًا تلو الآخر أحدث تحركات كل منصة في النصف الأول من 2026:

GitHub Spec Kit: مرجع تنفيذي ببوابات خماسية المراحل. أُطلق المشروع مفتوح المصدر في سبتمبر 2025، وبحلول النصف الأول من 2026 أصبح المرجع التنفيذي المعتمد في الصناعة. 5 أوامر أساسية + أمران تكميليان: /speckit.constitution (مبادئ غير قابلة للتفاوض)، /speckit.specify (ماذا سنبني ولماذا)، /speckit.plan (كيف ننفذ التغيير)، /speckit.tasks (تقسيم المهام)، /speckit.implement (التنفيذ)، بالإضافة إلى /clarify و /analyze. التصميم المحوري هنا هو الاستقلال عن النموذج — نفس ملفات spec/plan/tasks لا ترتبط بوكيل تنفيذ بعينه، بل يمكن لأدوات مثل Claude Code وCopilot وCursor وCodex CLI وGemini CLI وopencode وWindsurf وQwen Code التعامل معها جميعًا. هذا ما جعله “بروتوكول SDD على مستوى المؤسسة” وليس مجرد منتج حصري لـ GitHub (تقييم vibecoding.app، يونيو 2026، درجة 0.816، مصدر ثانوي).

AWS Kiro: دمج الحوكمة التنظيمية في بيئة التطوير المتكاملة. أُطلق في يوليو 2025، وتطوّر خلال النصف الأول من 2026 ليصبح بيئة تطوير متكاملة (Agent IDE) كاملة. يعتمد على سير عمل من ثلاث مراحل: المتطلبات ← التصميم ← المهام. الفارق الجوهري عن Spec Kit يكمن في “الخطافات” (hooks) — إذ يمكن لملفات المواصفات (spec) في Kiro تشغيل إجراءات وكيل محددة مسبقًا، مما يتيح دمج خطوات تتطلب أنظمة خارجية مثل الامتثال التنظيمي والتدقيق والنشر مباشرةً في سير العمل. إذا كنت تريد إجبار الفريق على كتابة المواصفات، فاختر Kiro — لأن Kiro لن يعمل ما لم تكتب spec (AWS Kiro الرسمي، يوليو 2025؛ وثائق Kiro.dev، 2026).

OpenAI Codex: AGENTS.md + Skills قابلة للتجميع. خلال الفترة 2025-2026، فرضت OpenAI ملفات AGENTS.md نفسها كعنصر محوري في النظام البيئي للتطوير. تمثل Skills الإضافة الأهم في النصف الأول من 2026: فهي تتيح تجهيز مهام مثل “قراءة جداول Excel” أو “توليد استعلامات SQL” أو “تنفيذ ترحيل البيانات” كوحدات جاهزة، يمكن استدعاؤها وتركيبها بمرونة مثل قطع الليغو. تجاوز عدد المستخدمين النشطين أسبوعياً لـ Codex حاجز 5 ملايين بحلول يونيو 2026، و20% منهم ليسوا مطورين — وهذه إشارة غالباً ما يتم تجاهلها: القيادة عبر الملفات التنظيمية لم تعد حصراً على فرق الهندسة، بل أصبحت مسؤولية الجميع؛ فرق المنتج والتشغيل وإدارة المخاطر جميعها تكتب ملفات AGENTS.md (إعلان OpenAI بتاريخ 2 يونيو 2026؛ تقييم thebcms.com لعام 2026، درجة 0.801).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. تستخدم Anthropic ملف CLAUDE.md كوثيقة تعليمات المشروع (دخل السوق الرسمي في فبراير 2026)، و.claude/rules/ (قواعد هرمية حسب الدلائل)، وSkills (سير عمل قابل للمشاركة). يُعد Claude Code الأداة الأعلى رضا بين المطورين في النصف الأول من 2026 — حيث أظهر استطلاع JetBrains 2026.1 درجة رضا 91% وصافي نقاط الترويج 54، مع تأكيد استطلاعين مستقلين (Pragmatic Engineer 2026.2) على ذلك. هذه أعلى نتيجة في سباق أدوات البرمجة بالذكاء الاصطناعي حاليًا (uvik.net 2026.5، درجة 0.956، تجميع مصادر أولية). حقق Claude Code قفزة من الصفر إلى إيرادات سنوية بقيمة 2.5 مليار دولار خلال 9 أشهر فقط (وفقًا لجولة تمويل Anthropic G في فبراير 2026)، مع 112 ألف نجمة على GitHub (مستودع Skills) — والمطورون يصوتون بأقدامهم، مما يؤكد القيمة الحقيقية للنهج القائم على القواعد.

Alibaba Qoder: مدفوع بالمعايير التنظيمية في السوق الصينية. صدر في أغسطس 2025، ثم رُقّي إلى الإصدار 1.0 في 15 مايو 2026، ليتحول رسميًا من “بيئة تطوير ذكاء اصطناعي متكاملة (AI IDE)” إلى “منصة عمل متكاملة لتطوير الوكلاء المستقلين (Autonomous Agent Development Workbench)”. تم إطلاق سير العمل القائم على المواصفات (Spec-Driven Workflow) بالتزامن مع وضع الاستكشاف الذاتي (Quest Mode) الذي ينفذ مهام متعددة الملفات بشكل مستقل، ووضع الخبراء (Expert Mode) الذي يعمل عبر فرق متوازية، ومستودع المعرفة (RepoWiki) الذي يبني خريطة معرفية للمستودعات البرمجية. وفي 28 مايو 2026، أُطلقت خدمة الوكلاء السحابيين (Cloud Agents) كبيئة تشغيل مُدارة بالكامل، تلتها في 21 يوليو ميزة “Qoder Security” للامتثال والأمان، وفي الشهر نفسه صدر إصدار الهواتف المحمولة (Android/iOS/HarmonyOS). وبتاريخ مايو 2026، تجاوز عدد المستخدمين العالميين 5 ملايين، وأدرج تطبيق DingTalk CLI هذه المنصة ضمن بيئات تنفيذ الوكلاء المدعومة لديه (Yahoo Finance 2025؛ Alibaba Cloud الرسمي 2026؛ Baidu Baike يوليو 2026).

النمط المشترك: توثيق “كيفية تعاوننا مع الذكاء الاصطناعي” بشكل صريح في ملفات، ووضعها في المستودع، بحيث يعمل جميع الأفراد وجميع وكلاء الذكاء الاصطناعي وفقًا لنفس المواصفات. تختلف تفاصيل التنفيذ بين المنصات الخمس (أسماء الملفات / عدد المراحل / آليات الخطاف)، لكن الهدف موحد تمامًا.

لماذا حدث هذا التوجه بشكل مركّز في النصف الأول من 2026؟ لأن حاجز قدرات الذكاء الاصطناعي قد تجاوزناه بالفعل — وكلاء Claude Code المستقلون، وتعدد وكلاء Codex بالتوازي، وإعادة هيكلة الملفات المتعددة في Cursor؛ لم يعد الذكاء الاصطناعي “أداة إكمال تلقائي”، بل “زميل عمل”. أي مستند تعريفيّ تقدّمه لزميل جديد، يجب أن يكون متاحًا أيضًا للذكاء الاصطناعي.

ثالثًا: القيادة بالمواصفات قدرة تنظيمية، وليست خيارًا تقنيًا

هذه أهم نقطة لصُنّاع القرار. القيادة بالمواصفات ليست اختيار أداة، بل تعريف “كيف تتعاون مؤسستنا مع الذكاء الاصطناعي”. سواء اخترت GitHub Spec Kit أو Claude Code ليس هو الأمر الجوهري؛ المهم هو هل وثّقت المواصفات في ملفات، ووضعتها في المستودع، وجعلت الجميع والذكاء الاصطناعي يعملون وفقًا لها.

بدون ذلك، فإن أفضل الأدوات لن تجعل الفريق أسرع إلا في تراكم المزيد من الديون التقنية.

عند النظر إلى هذا الأمر في سياق النشر الواسع النطاق خلال النصف الأول من عام 2026، تصبح الأدلة أكثر إقناعًا. في مراجعة السنة المالية 2026 الصادرة في يوليو 2026، صنّفت Microsoft حالتي EY وAtos كقالب “المؤسسة الرائدة” (Frontier Firm) — ليس لأن النماذج كانت جديدة، بل لأن هاتين المؤسستين كانتا أول من أجابا على سؤال “كيف نستخدم الذكاء الاصطناعي؟”:

EY: الحوكمة أولًا، ثم التوسع يحقق النتائج. خلال الفترة 2024-2025، عمّمت EY أداة Microsoft 365 Copilot على 150 ألف موظف، محققةً توفير 2.5 مليون ساعة عمل وما يقارب 250 مليون دولار أمريكي. الشرط الأساسي كان “بناء إطار حوكمة الذكاء الاصطناعي أولًا”: استخدمت EY منصة Power Platform وCopilot Studio وAzure وFoundry وFabric لبناء سلسلة أدوات موحّدة، واضعةً المعايير والامتثال والتدقيق في بنية أساسية واحدة. وهذا ما مكّنها لاحقًا من تحقيق تسريع بنسبة 95% في بعض العمليات، وخفض تكاليف العمليات المالية بنسبة 37%، وتقليل سير العمل اليدوي بنسبة تصل إلى 90%. وكان نائب رئيس EY صريحًا في جولة AI Tour 2026: “نحن لم ننشر الذكاء الاصطناعي ثم نضيف الحوكمة لاحقًا، بل بنينا الحوكمة أولًا ثم نشرنا الذكاء الاصطناعي”.

Atos: منصة تحكم موحّدة لـ 19,000 وكيل ذكي. تُعد Atos من أوائل المؤسسات عالميًا التي اعتمدت Microsoft 365 E7 (Frontier Suite)، حيث وفّرت Copilot لـ 56,000 موظف عبر 54 دولة. وتُشغّل حاليًا 19,000 وكيل ذكي (AI agent) — من أقسام تكنولوجيا المعلومات الداخلية، إلى الوحدات التجارية، وصولًا إلى مشاريع العملاء، وكلها تُبنى عبر Foundry و Copilot Studio. المفتاح الذي جعل هذا النجاح ممكنًا هو “منصة تحكم موحّدة”: Entra (للهوية) + Defender (للأمان) + Intune (للأجهزة) + Purview (للامتثال) + Agent 365 (لحوكمة الوكلاء)، وهذه العناصر الخمسة مترابطة معًا. هذا الربط، إذا ما قورن بقطاع المالية، يعادل دمج متطلبات “الامتثال الأمني + تقييم نقل البيانات عبر الحدود + تسجيل الخوارزميات + التدقيق + حوكمة النماذج” — أي أنه بنية حوكمة متكاملة، وليس مجرد أدوات ذكاء اصطناعي منفردة.

مفارقة مايكروسوفت في “تغيير المؤسسات”. في تقرير مؤشر اتجاهات العمل لعام 2026، اعترفت مايكروسوفت نفسها بأمر جوهري: “وتيرة تغيير المؤسسات تتخلف عن وتيرة الاستخدام الفردي”. من بين 20,000 مستخدم للذكاء الاصطناعي شملهم الاستطلاع، 82% من القادة يخططون لتوسيع القوى العاملة باستخدام وكلاء الذكاء الاصطناعي خلال 12-18 شهرًا، لكن 24% فقط أكملوا النشر على مستوى المؤسسات. 81% من القادة يتوقعون أن يتم دمج وكلاء الذكاء الاصطناعي بشكل متوسط أو كبير في استراتيجياتهم — ولكن مرة أخرى، 24% فقط فعلوا ذلك بالفعل. هذا يعني أن الغالبية العظمى من الشركات تفصلها مسافة 12-18 شهرًا بين “الاستعداد” و”الإنجاز”، والسؤال هو كيف يتم سد هذه الفجوة، الاعتماد على الحوكمة والمعايير هو الركيزة الأساسية.

المصدر: Microsoft FY26 retrospective 2026.7.28؛ Microsoft 2026 Work Trend Index Annual Report 2026.5.5 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net، مصدر أولي PDF)؛ تحليل Futurum Group 2026.1.26 (مصدر ثانوي).

الدرس الأول: الاستثمار في الحوكمة عائد استثماري مرتفع.

يقدّم تحليل CodeRabbit أساسًا واضحًا لحساب العائد على الاستثمار: معدل مشاكل الكود الناتجة عن الذكاء الاصطناعي يبلغ حوالي 1.7 ضعفًا، بينما ينخفض عدد الثغرات الأمنية بمقدار 2.74 ضعفًا. وهذا يعني:

  • أعمال إعادة صياغة أقل (في القطاع المالي، إعادة مراجعة الامتثال الواحدة قد تستغرق من 2 إلى 4 أسابيع)
  • حوادث أمنية أقل (غرامات تنظيمية وخسائر في السمعة نتيجة أي تسرب للبيانات)
  • تكاليف صيانة أقل (انخفاض الديون التقنية بنسبة 40% يُعد رقمًا شائعًا)

كتابة ملف مواصفات مشروع بصيغة CLAUDE.md أو AGENTS.md هي أعلى إجراءات الهندسة عائدًا على الاستثمار في عصر الذكاء الاصطناعي. حالة EY توفّر تحويلًا واقعيًا للأرقام — 150 ألف موظف يستخدمون Copilot، مع توفير 250 مليون دولار. لاحظ أن EY لم تحقق هذا التوفير لأن “الأداة قوية”، بل لأن “المواصفات هي التي حوّلت قيمة الأداة إلى نتائج ملموسة”.

الدرس الثاني: دمج المواصفات في العمليات المؤسسية، لا الاعتماد على الأفراد.

إذا بقيت المواصفات حبيسة عقل مهندس خبير واحد، فإنها تضيع بمجرد انتقال الموظفين. يجب ترسيخها في:

  • وثائق المستودع (AGENTS.md / CLAUDE.md / constitution.md)
  • بوابات CI (فحص تلقائي للالتزام بالمواصفات)
  • إعدادات مشتركة للفريق (نظام Skills يتيح للفريق بأكمله استخدامها)

دع القواعد تصبح أصلًا تنظيميًا، وليس مهارة فردية. هذا الأمر بالغ الأهمية في القطاع المالي—فمتطلبات الامتثال، وقواعد الأمان، وقواعد العمل لديكم كلها أصول على مستوى المؤسسة، وليست مجرد “خبرة” يمتلكها مهندس معين. وكلاء Atos البالغ عددهم 19,000 وكيل يعملون في 54 دولة، لأن الحوكمة هنا ليست “شخصًا يفهم”، بل “نظام يُلزِم”.

الدرس الثالث: البوابات أهم من السرعة.

البوابات الخمس في GitHub Spec Kit (constitution ← specify ← plan ← tasks ← implement)، وقاعدة Claude Code “لا تكتب كودًا قبل فشل الاختبارات”، واشتراط Kiro “لا يمكن البدء بدون كتابة spec”، كلها تفعل الشيء نفسه: إضافة “فرامل” بين الذكاء الاصطناعي والمخرجات النهائية. كل خطوة تُنتج أثرًا قابلًا للمراجعة (spec.md، plan.md، tasks.md)، ويمكن رفضها أو تعديلها قبل توليد الكود.

كلما زادت استقلالية الذكاء الاصطناعي، زادت حاجته إلى البوابات. لجنة مراجعة التغييرات (Change Advisory Board) في القطاع المالي، وعمليات تسجيل الخوارزميات، وتقييم الأمان الوطني (NCA Essential Cybersecurity Controls (ECC)—وهو ما يعادل تقييم الأمان السيبراني المتدرج في الصين)، كلها في جوهرها بوابات تُضاف قبل الإنتاج. كود الذكاء الاصطناعي يحتاج أيضًا إلى بوابات مماثلة، لكن بشكل مختلف. الفرق الـ 62% في تقرير New Relic 2026 الذين “يثقون بأنفسهم وينشرون دون مراجعة”، يدفعون ثمن هذه الثقة بمعدل حوادث أعلى (78%).

تنفيذ معايير صناعة المالية ثلاث مراحل (2026 H1 النسخة العملية) المرحلة الأولى: فحص القواعد 2-4 أسبوعا | أطول وقت، ROI أعلى قائمة المتطلبات الحكومية (الوضعية/الخروج/التسجيل) القواعد الأمنية (كلمات السر/التشفير/السجلات) قواعد الأعمال (المحافظة/التجارة/التقدير) القيود التقنية (الواجهات القديمة/حواجز الإصدار) إدارة الموردين (العقود/التحقق/المسؤولية) تجميع القواعد المتفرقة تظمها في وثائق مُقروءة المرحلة الثانية: تخزينها في المخازن 1-2 أسبوعا｜إدخالها في المخازن، التحميل الآلي CLAUDE.md / AGENTS.md constitution.md تعريف المهارات (التدفق المشترك) تصميم تدفقات التحكم (المرحلة الخمس) .claude/rules/ (القواعد المترتبة) إدخال القواعد في المخازن، التحميل الآلي المرحلة الثالثة: التدوين المستمر｜من أدوات إلى قدرات المنظمة التحكم بالمرحلة المستمرة (التحقق الآلي) مشاركة المهارات تقييم ربع السنوي قياس (معدل العيوب/معدل النجاح) حوكمة الوكلاء (Agent 365) المعايير تصبح أصول المنظمة عدم الاعتماد على الأفراد

المرحلة الأولى هي الأكثر استهلاكا للوقت، ولكن أعلى عائد استثمار
معظم القواعد المالية للمنظمات منتشرة في المستندات/البريد الإلكتروني/الأدمغة، والتنظيم الأولي يستغرق 3-8 أسابيع

رابعًا: المراحل الثلاث الفعلية للتطبيق في النصف الأول من 2026

بأخذ القطاع المالي كمثال للمراحل الثلاث، يمكن للقطاعات الأخرى شديدة التنظيم الاسترشاد بهذا النموذج. ممارسات EY و Atos في النصف الأول من 2026 تطابق هذه المراحل الثلاث تمامًا.

المرحلة الأولى: جرد القواعد (2-4 أسابيع).

هذه هي المرحلة الأكثر استهلاكًا للوقت ولكنها الأعلى عائدًا على الاستثمار. الهدف هو حصر جميع القواعد المتناثرة في أماكن مختلفة:

  • المتطلبات التنظيمية: الحد الأدنى الأساسي للقطاع المالي = التصنيف الأمني المستوى الثالث + تقييم نقل البيانات عبر الحدود + تسجيل الخوارزميات (نقص أي عنصر منها يعني عدم التوسع في نشر الذكاء الاصطناعي)، بالإضافة إلى متطلبات التقارير الرقابية، وحماية معلومات العملاء، وقيود تدفق البيانات عبر الحدود، وتحديد البيانات التي يمكن إطلاع الذكاء الاصطناعي عليها
  • القواعد الأمنية: إدارة كلمات المرور، معايير التشفير، معالجة الحقول الحساسة، متطلبات السجلات
  • القواعد التشغيلية: عتبات إدارة المخاطر، شروط تسوية المطالبات، حدود المعاملات، منطق الفوترة
  • القيود التقنية: واجهات الأنظمة القديمة، تسمية قواعد البيانات، قيود إصدارات الأطر البرمجية
  • حوكمة الموردين: كيفية اشتراط استخدام موردينا في العقود، وكيفية تدقيق استخدام الموردين للذكاء الاصطناعي

السيناريو النموذجي: خلال مرحلة الجرد، تكتشف إحدى شركات الأوراق المالية أن القواعد مبعثرة في عدد كبير من مستندات Word، وويكي JIRA، ورسائل البريد الإلكتروني الشخصية، وجداول Excel — ولا يتم الحصول على قائمة قواعد منظمة إلا بعد عملية فرز شاملة. أما نهج Atos فهو أكثر منهجية — إذ يقومون مباشرة بتقسيم القواعد إلى خمس فئات: “الامتثال، الأمن، الأعمال، التقنية، الموردون”، ولكل فئة سير عمل حوكمة خاص بها، ويتم ربطها جميعاً بمستوى التحكم الموحد في Agent 365.

هذه ليست مهمة تقنية، بل مهمة تنظيمية — عليك أن تجمع قسم الامتثال وقسم الأمن وقسم الأعمال معاً، وتدوّن القواعد التي يتفق عليها الجميع. في المرة الأولى التي تقوم فيها بهذا، تحتاج المؤسسات المالية عادةً من 3 إلى 8 أسابيع — لكن هذا أصل تنظيمي دائم.

المرحلة الثانية: الإيداع في المستودع (1-2 أسبوع).

تُكتب القواعد التي تم جمعها في المرحلة الأولى كمستندات وتُودَع في المستودع. يستخدم GitHub Spec Kit ملف constitution.md، وClaude Code يستخدم CLAUDE.md، وOpenAI Codex يستخدم AGENTS.md، وAlibaba Qoder يستخدم Spec Workflow. تختلف أسماء الملفات، لكن الهدف واحد — أن يتم تحميل القواعد تلقائياً بمجرد فتح الذكاء الاصطناعي للمستودع.

هيكل مقترح (النمط السائد للنصف الأول من 2026):

  • نظرة عامة على المشروع: ما هو الغرض من هذا النظام؟ ومن هم المستفيدون منه؟
  • مبادئ غير قابلة للتفاوض: خطوط حمراء أمنية، خطوط حمراء للامتثال التنظيمي، وخطوط حمراء للأعمال.
  • الحزمة التقنية والقيود: ما هي الأطر (Frameworks) المستخدمة؟ ما هي قاعدة البيانات؟ ما هي مواصفات الواجهات (API)؟
  • معايير البرمجة: اصطلاحات التسمية، هيكل الدلائل، والحد الأدنى لتغطية الاختبارات (لا نفرض أسلوب TDD كإيقاع إلزامي — فقط حدد نسبة التغطية، المسارات الإجبارية للاختبار، والمسارات المحظورة. TDD خيار تنظيمي وليس متطلبًا صارمًا).
  • قواعد العمل: منطق إدارة المخاطر، قواعد المعاملات، وقواعد الفوترة.
  • المتطلبات التنظيمية: الامتثال للتصنيف الأمني (等保 - Dengbao، وهو نظام التصنيف الأمني الإلزامي في الصين)، نقل البيانات عبر الحدود، التقارير الرقابية، وما إذا كانت خوارزميات الذكاء الاصطناعي التوليدية تتطلب تسجيلًا رسميًا.
  • سياسة استخدام الذكاء الاصطناعي: في أي الحالات يمكن استخدام الذكاء الاصطناعي؟ وما الحالات التي تتطلب مراجعة بشرية إلزامية؟ وما هي قواعد نقل البيانات عبر الحدود؟
  • حوكمة الموردين: بنود العقود، آليات التدقيق، وتوزيع المسؤوليات.

الملحق: هيكل CLAUDE.md للقطاع المالي (حوالي 200 سطر، قابل للتعديل المباشر)

فيما يلي هيكل جاهز لملف CLAUDE.md مصمم لمشروع تحديث الأنظمة الأساسية لأحد البنوك المساهمة، منظم وفق الترتيب التالي: “المبادئ غير القابلة للتفاوض ← المتطلبات التنظيمية ← سياسة استخدام الذكاء الاصطناعي ← قواعد العمل ← القيود الهندسية”. لا حاجة للبدء من الصفر — فقط املأ الفراغات بالقواعد الخاصة بمؤسستك.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
# CLAUDE.md — <اسم النظام> — لوائح التعاون مع الذكاء الاصطناعي

> النطاق: <اسم النظام> v<الإصدار>، جميع وكلاء الذكاء الاصطناعي (Claude Code / Cursor / Copilot / Codex)
> العاملون في هذا المستودع ملزمون بالامتثال لهذه اللوائح. يدير هذه اللائحة <لجنة الحوكمة>،
> وتخضع للمراجعة الفصلية.
> آخر تحديث: YYYY-MM-DD

## 1. نظرة عامة على المشروع
- **الموقع التجاري**: اسم النظام الأساسي / شريحة العملاء / أنواع المعاملات الرئيسية
- **السلسلة الحرجة**: المعاملة → إدارة المخاطر → التسوية → المطابقة → الإبلاغ
- **نافذة عدم التوفر**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (ممنوع إدخال أي تعديلات)
- **التبعيات الجوهرية**: النظام <X> المنبع، النظام <Y> المصب، منصة الإبلاغ التنظيمي

## 2. مبادئ غير قابلة للتفاوض (الخطوط الحمراء — أي انتهاه = رفض الدمج)

### 2.1 الخطوط الحمراء للأمان
- كلمات المرور والمفاتيح وToken تمر جميعها عبر KMS (خدمة إدارة المفاتيح)، **يُحظر الترميز الثابت (Hardcoding)**، **يُحظر طباعتها في السجلات**
- الحقول الحساسة للعملاء (رقم الهوية / رقم البطاقة / CVV / رقم الهاتف) **يجب تشفيرها عند التخزين**، ويُحظر تخزينها كنص واضح في قاعدة البيانات
- يُحظر ظهور ما يلي في السجلات: رقم الهوية الكامل، رقم البطاقة الكامل، كلمة المرور بنص واضح، تركيبة اسم العميل + رقم الهاتف
- استدعاءات الواجهات الخارجية يجب أن تمر عبر بوابة API، ويُحظر الاتصال المباشر

### 2.2 الخطوط الحمراء للامتثال
- أي كود يولّده الذكاء الاصطناعي يتضمن وصولاً إلى بيانات العملاء يجب أن يحمل في وصف PR علامة "وصول البيانات: <الحقل>"
- يُحظر نقل البيانات عبر الحدود، **أي نقل بيانات إلى الخارج يجب أن يمر بإجراء تقييم نقل البيانات عبر الحدود** (يُرجى التواصل مع إدارة الامتثال)
- القرارات الخوارزمية (الائتمان / تسعير التأمين / مكافحة الاحتيال) يجب أن تحتفظ بإدخال للمراجعة البشرية
- أي تغيير في النموذج يتطلب تسجيل الخوارزميات، ويجب الاستشهاد برقم التسجيل في وصف PR

### 2.3 الخطوط الحمراء للأعمال
- تغيير عتبات إدارة المخاطر يتطلب توقيعًا مزدوجًا من مسؤول المخاطر ومسؤول الأعمال
- أي عملية تتضمن أموال العملاء يجب أن تتضمن تصميمًا متكررًا (Idempotent) + إمكانية التراجع عند الفشل
- حدود المعاملات والرسوم ومعايير المنتجات تمر عبر منصة إدارة المعلمات، ولا يجوز ترميزها بشكل ثابت في الكود

## 3. المكدس التقني والقيود
- **اللغات**: Java 17 (الأساسي) / Kotlin (الوحدات الجديدة) / SQL (قاعدة البيانات)
- **الإطار**: Spring Boot 3.x + Spring Cloud Alibaba
- **قاعدة البيانات**: OceanBase 4.x (وضع توافق MySQL)، **يُحظر استخدام المفاتيح الخارجية**
- **مواصفات الواجهات**: gRPC داخليًا على الدوام؛ الواجهات الخارجية OpenAPI 3.0؛ RESTful محصور بواجهات الإدارة فقط
- **اتفاقيات التسمية**: أصناف Java بصيغة PascalCase، الدوال بصيغة camelCase، الثوابت UPPER_SNAKE؛ أسماء الجداول `t_<المجال_التجاري>_<الكيان>`؛ الفهارس `idx_<الجدول>_<الحقل>_<الترتيب>`
- **بنية الحزم**: `com.<الشركة>.<المجال_التجاري>.<المجال_الفرعي>.<الطبقة>` (مثل `com.bank.pay.tx.core.service`)

## 4. معايير الكود
- **الحد الأدنى لتغطية الاختبارات**: السلسلة الحرجة ≥ 80%، فئات الأدوات ≥ 60%، أي كود جديد يُسلَّم عبر PR يجب أن يكون مصحوبًا باختباراته
- **المسارات التي يجب اختبارها**: جميع controllers يجب أن تحتوي على اختبارات تكاملية (بما في ذلك مسارات الفشل)؛ جميع فروع enum يجب أن تحتوي على اختبارات وحدات
- **المسارات الممنوعة**: يُحظر تعديل دليل `<الوحدات_التاريخية_الثقيلة>` — يجب أولًا إنشاء طبقة تكييف
- **إدارة التبعيات**: أي إضافة لطرف ثالث تمر عبر فحص SCA + موافقة أمنية

## 5. قواعد الأعمال (حسب المجال)
### 5.1 المعاملات
- حد المبلغ لكل معاملة: <المبلغ>؛ حد المبلغ اليومي: <المبلغ>؛ أي تجاوز يستلزم موافقة بشرية
- نافذة وقت المعاملة: <HH:MM> ~ <HH:MM>
- حكم المعاملة المكررة: نفس <الحقل> خلال <النافذة_الزمنية> يُعد تكرارًا

### 5.2 إدارة المخاطر
- ترتيب أولوية مطابقة القوائم السوداء: القائمة السوداء الداخلية → القائمة الصادرة عن الجهات التنظيمية → التجميد القضائي
- حد مخرجات نموذج مكافحة الاحتيال: <الدرجة>؛ في حال التجاوز يجب المراجعة البشرية الثانية

### 5.3 الفوترة
- أي تغيير في الرسوم يجب أن يتضمن رقم إصدار + تاريخ السريان
- تُحسب الطلبات التاريخية بسعر الساري في تاريخ السريان، دون رجعية

## 6. متطلبات الامتثال
- MLPS المستوى 3: <جهة_التقييم>، <تاريخ_التقييم_القادم>
- تقييم نقل البيانات عبر الحدود: النطاق (وحدات الأعمال العابرة للحدود فقط)
- تسجيل الخوارزميات: النطاق (الائتمان / تسعير التأمين وغيرها من الخوارزميات الرئيسية)، رقم التسجيل `<الرقم>`
- التنظيمات الرقابية: جدول ربط الحقول لـ CBIRC / بنك الشعب الصيني في `<المسار>`

## 7. لوائح استخدام AI
- **السيناريوهات التي يجوز فيها استخدام AI**: قوالب CRUD، توليد اختبارات الوحدات، المسودات الأولية للوثائق، اقتراحات تحسين SQL
- **السيناريوهات التي تستلزم مراجعة بشرية إلزامية**: منطق إدارة المخاطر، قواعد الفوترة، التحكم في الصلاحيات، التشفير وفك التشفير، البيانات العابرة للحدود
- **السيناريوهات التي يُمنع فيها تنفيذ AI بشكل مستقل**: مواد موافقة Change Advisory Board (CAB) (مجلس استشاري للتغيير)، تنفيذ تغييرات الإنتاج، الاستجابة للطوارئ
- **قواعد نقل البيانات إلى الخارج**: بيانات التدريب / الموجهات (Prompts) / سجلات المخرجات — لا تُنقل إلى الخارج بأي حال؛ يُفضّل استخدام الإصدار المُنشَر محليًا (<المورّد>)
- **متطلبات التدقيق**: أي كود يولّده الذكاء الاصطناعي يجب أن يحمل في وصف PR علامة "مساعدة AI: <اسم_الأداة>"

## 8. حوكمة الموردين
- **تأهيل الموردين**: يجب تقديم تقرير SOC 2 / ISO 27001؛ نماذج AI يجب أن تكون مصحوبة ببطاقة النموذج (Model Card)
- **بنود العقود**: ملكية البيانات، قابلية تفسير النموذج، بنود الخروج، حق التدقيق
- **آلية التدقيق**: تدقيق فصلي لاستخدام الموردين لـ AI؛ تدقيق شهري للموردين عاليي المخاطر

## 9. الحوكمة والتحديث
- **المالك**: <لجنة_الحوكمة> (الامتثال + الأمان + الهندسة المعمارية + الأعمال)
- **تكرار التحديث**: مراجعة فصلية؛ التغيير الطارئ يمر عبر المسار السريع (توقيع مزدوج + إعلان لمدة 24 ساعة)
- **سجل التغييرات**: راجع `CLAUDE_CHANGELOG.md`
- **معالجة المخالفات**: المخالفة الأولى = إنذار + تدريب إلزامي؛ المخالفة الثانية = تعليق أدوات AI؛ المخالفة الثالثة = إلغاء الصلاحيات

هذا الهيكل ليس “إجابة معيارية”، بل “قالب للتعبئة”. ما يُملأ في كل خانة أهم من عدد الكلمات المكتوبة — فالفراغات تكشف الجزء الذي “لم تُحسم رؤيته” في شركتك.

مثال نموذجي: في أحد البنوك المساهمة، خُصص ملف CLAUDE.md لقواعد معالجة كلمات المرور — بحيث يلزم أي كود يولّده الذكاء الاصطناعي يتعلق بكلمات المرور باستدعاء واجهة إدارة المفاتيح الداخلية، ويُمنع ترميزها بشكل ثابت في الكود. هذا النوع من القواعد يمثل نسبة مرتفعة من أسباب رفض المراجعات الامتثالية.

أحد الحقول الجديدة المهمة في النصف الأول من 2026 هو Skills/تعريفات سير العمل — لم تعد مجرد توثيق، بل سلاسل أدوات يمكن للذكاء الاصطناعي استدعاؤها. نظام Skills في Claude Code (الذي دخل السوق الرسمي لـ Anthropic في فبراير 2026، وحقق 112 ألف نجمة على GitHub) يحوّل عمليات مثل “قراءة ملف Excel” و”توليد استعلامات SQL” و”تشغيل ترحيل البيانات” إلى سير عمل قابلة للمشاركة. هذا هو التطور الجوهري في النصف الأول من 2026 الذي تقوده المعايير: المعايير لم تعد مجرد قيود، بل سير عمل قابلة للتنفيذ.

المرحلة الثالثة: الأنسنة المؤسسية (مستمرة).

كتابة المواصفات ليست النهاية، بل هي البداية. عليك تحويلها إلى جزء من عمليات المؤسسة:

  • بوابة التكامل المستمر (CI Gate): فحص تلقائي للتأكد من التزام الكود بالمواصفات (مثل كشف كلمات المرور المضمنة في الكود، أو الحقول الحساسة غير المشفرة)
  • مشاركة الإعدادات على مستوى الفريق: استخدام نظام Skills لتمكين الفريق بأكمله من العمل بنفس مجموعة المواصفات
  • آلية تحديث دورية: عندما تتغير القواعد، يجب أن تتغير المواصفات تبعًا لذلك (مراجعة ربع سنوية)
  • القياس والتغذية الراجعة: تتبع معدل العيوب في الكود المُنتج بالذكاء الاصطناعي، ومعدل اجتياز مراجعات الامتثال، ومعدل إعادة العمل
  • حوكمة الوكلاء: توسيع نطاق الحوكمة من البشر لتشمل وكلاء الذكاء الاصطناعي — ما تقوم به Atos على منصة Agent 365 هو جعل هذا الأمر “على مستوى النظام” بدلاً من “على مستوى الفرد”

في النصف الأول من 2026، جعلت كل من EY وAtos المرحلة الثالثة “قدرة مؤسسية”. إن توفير EY البالغ 2.5 مليون ساعة يعود إلى التنفيذ الصحيح للمرحلتين الأولى والثالثة — المرحلة الثانية كانت مجرد ترجمة القواعد إلى مستندات يمكن للذكاء الاصطناعي قراءتها.

خامسًا: نسخة القطاعات شديدة التنظيم: ثلاث طرق هندسية لدمج الامتثال

في القطاعات شديدة التنظيم مثل المالية والاتصالات والرعاية الصحية، يواجه تطبيق القيادة بالمواصفات تحديًا إضافيًا مقارنة بالقطاعات العامة — الامتثال ليس إضافة خارجية للعملية، بل جزء مدمج في الكود نفسه. فيما يلي ثلاث طرق لدمج الامتثال تم التحقق منها في النصف الأول من 2026، ويمكن لمسؤولي التقنية (CIO) ومسؤولي التحول الرقمي الرجوع إليها مباشرة عند تصميم الهيكل التنظيمي.

5.1 دمج ممثل الامتثال داخل فريق التدفق: جعل الامتثال “حاضرًا” بدلًا من “موافقة لاحقة”

النهج التقليدي: فريق التطوير يكتب الكود، وفريق الامتثال يراجعه بعد فوات الأوان — وعندما يكتشف التدقيق مشكلة، يكون الكود قد نُشر بالفعل منذ أسبوعين، وتكلفة إعادة العمل تتراوح بين 2-4 أسابيع. جوهر المشكلة هو أن الامتثال يقع في نهاية المسار.

النهج الجديد: **دمج ممثل امتثال داخل كل فريق تدفق (stream-aligned team)**، عبر هيكل تقارير مزدوج: “خط صلب” إلى إدارة الامتثال و”خط متقطع” إلى فريق الأعمال. التصميم التفصيلي:

  • التوظيف: ممثل امتثال واحد لكل 6-8 فرق تدفق، تابع إداريًا لإدارة الامتثال، لكن مكتبه الفعلي داخل فريق الأعمال — وليس “إعارة” مؤقتة
  • مؤشرات الأداء المتقطعة: 50% من وزن تقييم ممثل الامتثال مرتبط بمؤشري “معدل عيوب الامتثال” و”معدل اجتياز المراجعة من المحاولة الأولى” لفريق الأعمال، وليس فقط “التغطية التدقيقية” التي تهم إدارة الامتثال
  • تدخل مبكر: يشارك ممثل الامتثال في الوقوف اليومي (مرة أسبوعيًا كافية)، ومراجعات Pull Request، والكود المُولَّد بالذكاء الاصطناعي يجب أن يمر عبر ممثل الامتثال قبل الدمج — وليس أن يُكتشف بعد الدمج ثم يُعالَج بأثر رجعي
  • الدعم الأداتي: يستخدم ممثل الامتثال Skills الخاصة بقوائم التحقق من الامتثال، بدلًا من المطابقة اليدوية بندًا بندًا

5.2 تحويل الامتثال إلى فريق تمكيني: تحويل القيود إلى إمكانات

النهج التقليدي: فريق الامتثال يعمل كـ”حارس بوابة”، وفريق الأعمال ينظر إلى الامتثال باعتباره “صانع المتاعب”. الطرفان في لعبة محصلتها صفر.

النهج الجديد: إعادة هيكلة فريق الامتثال وفق نموذج الفريق التمكيني (Enabling Team) في Team Topologies — لا يكتبون الكود مباشرة، ولا يراجعون طلبات السحب (PR) مباشرة، لكنهم يوفّرون ثلاثة أشياء تمكّن فريق الأعمال من “الامتثال الذاتي”:

  1. فحوصات الامتثال داخل خط CI: تحويل نقاط الامتثال عالية التكرار — مثل ترميز كلمات المرور بشكل ثابت، الحقول الحساسة بنص واضح، نقل البيانات عبر الحدود، ونقاط القرار الخوارزمي — إلى بوابات إلزامية في GitHub Actions / GitLab CI. طلبات السحب من الفرق التجارية تُطلق فحصًا تلقائيًا، وأي عدم امتثال يفشل فورًا — دون الحاجة إلى مراجعة يدوية من مسؤول الامتثال.

  2. تحويل المتطلبات التنظيمية إلى “قيود بيئية استباقية” (Affordance): على سبيل المثال، عند تطوير ميزات تتعامل مع بيانات العملاء، يظهر تنبيه من إضافة IDE مثل “يُوصى باستدعاء KMS لهذا الحقل”؛ وعند كتابة السجلات، يتم اكتشاف تلقائي لما إذا كانت تحتوي على معلومات حساسة مع إطلاق إنذار. **الهدف هو أن تصبح متطلبات الامتثال “إجراءً طبيعيًا يحدث أثناء التطوير”**، وليس “اكتشاف المخالفات بعد فوات الأوان قبل الإطلاق”.

  3. مكتبة Skills مشتركة + تدريب على الامتثال: يحافظ فريق الامتثال على مجموعة “Skills للامتثال”، تُستدعى مباشرة عند انضمام موظف جديد أو انتقال فريق بين الأقسام — تحويل المعرفة الامتثالية من “مستندات” إلى “أدوات قابلة للتنفيذ”.

سيناريو نموذجي: أطلق أحد البنوك الإقليمية في النصف الأول من 2026 بوابات امتثال CI + تنبيهات IDE، مما خفّض متوسط الوقت للفرد في مراجعة امتثال كود الذكاء الاصطناعي من 45 دقيقة/مرة إلى 8 دقائق/مرة. الجوهر ليس أن “المراجعة أصبحت أسرع”، بل أن الكود “لا يخطئ” منذ لحظة توليده.

5.3 الامتثال ثنائي السرعة: مواءمة متدرجة مع إيقاع الأعمال

التفصيل الأخير: الامتثال لا يجب أن يُطبَّق بنهج “مقاس واحد يناسب الجميع”. قسّم القواعد إلى مستويين حسب درجة المخاطر:

  • القواعد عالية المخاطر (التي تمس أموال العملاء / القرارات الخوارزمية / البيانات العابرة للحدود / خطوط الامتثال الحمراء) تخضع لحوكمة صارمة: مراجعة بشرية إلزامية + تأكيد ثانٍ من الذكاء الاصطناعي + تسجيل لدى Change Advisory Board (Change Advisory Board (CAB))
  • القواعد منخفضة المخاطر (قوالب CRUD / أكواد الأدوات / توليد المستندات) تخضع لحوكمة ذاتية: فحص تلقائي عبر CI فقط، دون الحاجة لمراجعة بشرية

مستوى التحكم في Atos Agent 365 هو في جوهره هذا التقسيم الطبقي — حيث يرتبط كل مستوى من الوكلاء بمتطلبات حوكمة مختلفة. عندما تُصنَّف قواعد الامتثال حسب درجة المخاطر، يشعر فريق الأعمال أن “الامتثال لا يعرقلني في كل خطوة”.

الخلاصة المجمّعة لهذه الأمور الثلاثة: دمج الامتثال ليس إضافة إجراء جديد، بل إعادة تصميم هيكل الفريق وحوافزه. إذا كان قسم الامتثال لديك لا يزال يعمل بنمط “المراجعة اللاحقة”، فسيتعثر تطبيق القيادة بالقواعد عند أصعب مرحلة — وهي “الأسس المؤسسية” — فقسم الامتثال يحتاج إلى التحول أولاً، وعندها فقط يمكن لفريق الأعمال أن يعمل بسلاسة مع القيادة بالقواعد.

سادسًا: أسئلة قد تخطر ببالك

“لدينا بالفعل معايير ترميز، فما الفرق بينها وبين هذا؟”

معايير الترميز تحكم “كيف تكتب الكود”، بينما القيادة بالقواعد تحكم “كيف تتعاون مع الذكاء الاصطناعي”. معايير الترميز لا تشمل: قواعد العمل، متطلبات الامتثال، استراتيجيات استخدام الذكاء الاصطناعي. القيادة بالقواعد هي جعل “مسار التعاون الكامل بين الإنسان والذكاء الاصطناعي” أمرًا صريحًا وواضحًا، وليست مجرد دليل أسلوب للكود.

هل كتابة المواصفات الفنية بالذكاء الاصطناعي تستحق العناء؟

“هل كتابة المواصفات الفنية بالذكاء الاصطناعي تستحق العناء؟”

الإجابة القصيرة: نعم، وبفارق كبير. البيانات المستقاة من CodeRabbit تُظهر أن العيوب البرمجية في الأكواد غير المقيدة بمواصفات فنية تزيد بنحو 1.7 ضعفًا، بينما ترتفع الثغرات الأمنية إلى 2.74 ضعفًا. في القطاع المصرفي، إعادة مراجعة واحدة للامتثال التنظيمي قد تستغرق من 2 إلى 4 أسابيع — أي أن توفير دورة مراجعة واحدة يعادل كتابة مواصفات فنية لشهر كامل. توفير 250 مليون دولار الذي أعلنته EY هو دليل ملموس على أن تحويل هذه الممارسة إلى قدرة مؤسسية يحقق عوائد حقيقية.

“لكن لا أحد في فريقنا يعرف كيف يكتب مواصفة فنية!”

لا بأس، فأنت لست بحاجة للبدء من الصفر. GitHub Spec Kit وClaude Code Superpowers وAWS Kiro جميعها توفر قوالب جاهزة. كل ما عليك فعله هو إدخال القواعد الخاصة بمؤسستك — ومعظمها قواعد امتثال وأمان، وهذه غالبًا ما تكون جاهزة بالفعل لدى إدارات الامتثال والأمان، لكنها لم تُوضع في مكان يمكن للذكاء الاصطناعي الوصول إليه.

“هناك الكثير من أدوات الذكاء الاصطناعي، فأيها نختار؟”

غير مهم. اختاروا ما تستخدمونه بالفعل. القواعد هي المحرك، وليست الأدوات — ملف CLAUDE.md يعمل في Claude Code وCursor وCodex؛ وAGENTS.md يعمل في بيئة OpenAI؛ وconstitution.md مستقل عن النموذج. المهم هو كتابة القواعد، لا تغيير الأدوات. EY تنشر على نظام Microsoft البيئي، وAtos كذلك — اختلاف الأدوات مجرد مظهر خارجي، أما توحيد هيكل الحوكمة فهو الجوهر.

“قانون الذكاء الاصطناعي الأوروبي (EU AI Act) يدخل حيز التنفيذ الكامل في أغسطس 2026 — فهل يؤثر ذلك علينا؟”

نعم. يدخل قانون الذكاء الاصطناعي الأوروبي (EU AI Act) مرحلة التنفيذ الكامل في 2 أغسطس 2026، ويفرض متطلبات امتثال إلزامية على أنظمة الذكاء الاصطناعي عالية المخاطر (بما في ذلك الائتمان، وتسعير التأمين، وفرز التوظيف، والبنية التحتية الحيوية) — إدارة المخاطر (المادة 9)، وحوكمة البيانات (المادة 10)، وشفافية التوثيق (المواد 11-13)، والإشراف البشري (المادة 14)، والدقة/المتانة (المادة 15). تصل الغرامات القصوى إلى 35 مليون يورو أو 7% من الإيرادات العالمية. بالنسبة للشركات الصينية التي تتوسع عالميًا، فإن السوق الأوروبية مسألة حتمية؛ وبالنسبة للشركات المحلية، فإن إطار قانون الذكاء الاصطناعي الأوروبي هو المعيار الأكثر استشهادًا به على مستوى العالم — قد لا تكون ملزمًا بتطبيقه مباشرة، لكن من الصعب عليك تجاوز آثاره غير المباشرة على مورديك وشركائك وأعمالك العابرة للحدود (whisperly.ai 2026؛ surecloud.com 2026.6؛ artificialintelligenceact.eu 2026.6).

“المقارنة المحلية: أوروبا تنظّم الذكاء الاصطناعي، فماذا ننظّم نحن؟”

يعتمد نهج الصين المحلي في حوكمة الذكاء الاصطناعي التوليدي على “ثلاثية”: تسجيل الخوارزميات + مراجعة بيانات التدريب + تقييم السلامة، مع دخول “التدابير المؤقتة لإدارة خدمات الذكاء الاصطناعي التوليدي” حيز التنفيذ في أغسطس 2023 بوصفها الأداة التنظيمية الأساسية. غير أن الفارق الأكبر بين النظامين لا يكمن في كثافة البنود، بل في الفلسفة التشريعية:

البُعدEU AI Actاللائحة الصينية “إجراءات إدارة خدمات الذكاء الاصطناعي التوليدي”
الموقع القانونيتشريع أفقي (يُطبَّق على جميع أنظمة الذكاء الاصطناعي)قاعدة قطاعية (تركّز على خدمات الذكاء الاصطناعي التوليدي)
تصنيف المخاطر4 مستويات (غير مقبول / مرتفع / محدود / أدنى)مستويان (ما يمسّ الأمن العام / الاستخدام التجاري العام)
توقيت الرقابةاستباقي (التسجيل يبدأ من مرحلة التطوير)لاحق (التسجيل بعد الإطلاق + تسجيل الخوارزميات)
الشفافيةعالية (إلزام بنشر ملخص مصادر بيانات التدريب وبطاقات النماذج)متوسطة (اشتراط امتثال بيانات التدريب دون إلزام بالكشف عن المصادر)
سقف العقوبات7% من الإيرادات العالمية أو 35 مليون يوروتعليق الخدمة / غرامات (عادةً مضاعفات الأرباح غير المشروعة)
نطاق التطبيقجميع الشركات التي تتجاوز عتبة الإيرادات العالميةجميع الكيانات التي تقدّم الخدمات داخل الأراضي الصينية

عمليًا، تخضع أنظمة الذكاء الاصطناعي في المؤسسات المالية الصينية عادةً لثلاث مجموعات من القواعد في آن واحد — “إجراءات إدارة الذكاء الاصطناعي التوليدي” (الطبقة الأساسية) + “إجراءات إدارة القروض عبر الإنترنت للبنوك التجارية” (طبقة الأعمال) + التقييم الأمني المُصنَّف + تسجيل الخوارزميات (طبقة الامتثال). وهذا يعني أن بناء الحوكمة التنظيمية في السوق الصينية **لا يمكن أن يستند ببساطة إلى إطار قانون الذكاء الاصطناعي الأوروبي (EU AI Act)**، بل يجب دمج المسارات الثلاثة المحلية — “امتثال بيانات التدريب + تسجيل الخوارزميات + الإبلاغ التنظيمي” — بالكامل داخل ملف CLAUDE.md.

أما بالنسبة للشركات التي تتوسع عالميًا: فإن “إدارة المخاطر + حوكمة البيانات + شفافية التوثيق + الإشراف البشري” — وهي المكونات الأربعة لقانون الذكاء الاصطناعي الأوروبي — تمثل أيضًا الاتجاه الذي تتجه إليه اللوائح الصينية تدريجيًا. ففي عام 2025، أظهرت ردود مكتب الإنترنت الصيني (CAC) على طلبات تسجيل الذكاء الاصطناعي التوليدي تأثرًا واضحًا بمستوى التفصيل الأوروبي. من يكتب اليوم معايير متوافقة مع قانون الذكاء الاصطناعي الأوروبي، فمن المرجح أن تكون متوافقة أيضًا مع اتجاهات التشديد المحلية خلال السنوات الثلاث القادمة (إعلانات تسجيل CAC 2025-2026؛ الامتثال لقانون الذكاء الاصطناعي الأوروبي يونيو 2026).

سابعًا: ما يعنيه هذا لصُنّاع القرار

الدرس الأول: كتابة ملف معايير مشروع بصيغة CLAUDE.md أو AGENTS.md هو أعلى إجراء هندسي عائدًا على الاستثمار في عصر الذكاء الاصطناعي.

الدرس الثاني: التنظيم القائم على المعايير قدرة مؤسسية، لا مجرد اختيار أداة.

لا يهم إن اخترت GitHub Spec Kit أو Claude Code، المهم هو: هل حددت “كيف تتعاون مؤسستنا مع الذكاء الاصطناعي؟” بدون هذا، حتى أفضل الأدوات ستجعل الفريق يتراكم عليه الديون التقنية بسرعة أكبر.

الدرس الثالث: ادمج المعايير في العمليات المؤسسية، ولا تعتمد على الأفراد.

إذا بقيت المعايير حبيسة عقل مهندس خبير واحد، فستضيع بمجرد انتقاله. يجب ترسيخها في وثائق المستودع، وبوابات CI، والإعدادات المشتركة للفرق، ومنصات حوكمة الوكلاء. اجعل المعايير أصلًا مؤسسيًا، لا مهارة فردية. شركة Atos تشغّل 19,000 وكيل عبر 54 دولة بنجاح، لأن الحوكمة ليست “شخصًا يفهم”، بل “نظام يفرض”.

الدرس الرابع: البوابات (Gatekeeping) أهم من السرعة.

GitHub Spec Kit بمراحله الخمسة المتدرجة، وقاعدة Superpowers “لا تكتب كودًا قبل فشل الاختبار”، واشتراط Kiro “لا بدء بدون مواصفات” — كلها بمثابة فرامل بين الذكاء الاصطناعي والمخرجات النهائية. كلما زادت قدرة الذكاء الاصطناعي، زادت الحاجة إلى حوكمة تسبقه. نسبة الحوادث البالغة 78% في تقرير New Relic لعام 2026 هي ثمن قيام 62% من الفرق بالنشر “بدون مراجعة”. مدراء تكنولوجيا المعلومات في القطاع المالي هم الأكثر إدراكًا لهذا: لجان مراجعة التغيير (Change Advisory Board (CAB))، وإجراءات تسجيل الخوارزميات، واختبارات الامتثال الأمني — كلها بوابات تُفرض قبل الإنتاج. كود الذكاء الاصطناعي يحتاج إلى بوابات مماثلة، بل وأكثر تقدّمًا.

مراجعة ذاتية عكسية (لا تجمّل الإجابة): هل مراجعات الامتثال لكود الذكاء الاصطناعي الذي يولّده فريقك تتطلب إعادة عمل متكررة؟ ما آخر مشكلة سبّبها كود مولّد بالذكاء الاصطناعي؟ إذا سألت المسؤول التقني “كيف نتعاون مع الذكاء الاصطناعي؟”، هل يستطيع تقديم وثيقة مكتوبة؟ إذا عجزت عن الإجابة عن أي من هذه النقاط الثلاث، فهذا يعني أن الحوكمة القائمة على المواصفات لم تُطبَّق بعد — اكتب المواصفات أولًا، ثم اشترِ الأدوات.

ثلاثة أسئلة إرشادية لصنّاع القرار

في الختام، ثلاثة أسئلة — ليست قائمة تحقق، بل أسئلة يمكنك استخدامها مباشرة في نقاشك مع فريقك:

  1. “إذا أُوقفت جميع أدوات الذكاء الاصطناعي غدًا، كم ستنخفض جودة الكود في فريقك؟” — يكشف هذا السؤال القيمة الحقيقية للحوكمة القائمة على المعايير: إذا كانت الإجابة “انخفاض ملحوظ”، فهذا يعني أن معاييرك لم تترسّخ بعد؛ أما إذا كانت “لا تغيير تقريبًا”، فهذا يعني أن الحوكمة بالمعايير تعمل بالفعل.
  2. “في مشروع الحوكمة بالمعايير لديكم، هل إدارة الامتثال “حارسة بوابة” أم “مُمكِّنة”؟” — إذا كانت الإجابة “حارسة بوابة”، فستتعطل سرعة التنفيذ بسبب اختناقات المراجعة؛ أما إذا كانت “مُمكِّنة”، فأنتم بالفعل على المسار الصحيح الذي ورد في القسم 5.2.
  3. “بعد 12–18 شهرًا، كيف سيتغير حجم فريقك؟” — إجابة تقرير Microsoft WTI 2026 هي أن 82% من القادة سيستخدمون وكلاء الذكاء الاصطناعي “لتوسيع” القوى العاملة. إذا كانت إجابتك “لن يتغير”، فإما أن أعمالك لا تنمو، أو أن تصميمك التنظيمي لم يواكب مكاسب الحوكمة بالمعايير.

لا توجد إجابات صحيحة موحّدة لهذه الأسئلة الثلاثة. لكن اتجاه الإجابة أهم من الإجابة نفسها.

الخطوة التالية

هذه هي المقالة السادسة في سلسلة “تحول هندسة البرمجيات في عصر الذكاء الاصطناعي”. بدأنا من قانون كونواي (التنظيم يحدد البنية)، ثم انتقلنا إلى Team Topologies (كيف تصمّم التنظيم)، ثم إلى انتقال الاختناق (الاختناق في التحقق وليس في البرمجة)، واليوم نصل إلى الحوكمة بالمعايير (استخدام التوثيق لتقييد سلوك الذكاء الاصطناعي).

المقال التالي (السابع)، سننظر إلى البنية التحتية الأساسية التي تدعم كل هذا — بروتوكول MCP (Model Context Protocol): لماذا يُطلق على البروتوكول مفتوح المصدر من Anthropic اسم “USB-C الخاص بالذكاء الاصطناعي”، ولماذا تبنّته OpenAI وGoogle وMicrosoft جميعًا، وكيف يجعل التشغيل البيني بين الأدوات والوكلاء المتعددين ممكنًا.

تريد تطبيق هذا الإطار على شركتك؟

عندما يدخل الحوكمة القائمة على المعايير إلى المؤسسة، فإن ما يحتاج إلى حل فعليًا هو عادةً عدة مسائل محددة: كيف تترسّخ القواعد الأساسية في ملفات CLAUDE.md / AGENTS.md، وكيف تُعالَج الشيفرة البرمجية القائمة لتتوافق مع المعايير، وكيف يُدمَج الامتثال التنظيمي، وما هي المقاييس التي ينبغي استخدامها لقبول التجارب الأولية.

حاليًا، نقدم ثلاثة أنواع من التعاون:

  • تدريب داخلي للشركات: بالاستناد إلى مشاريعك الفعلية، نُنجز توثيق المعايير، وتصميم بوابات CI، ومسار دمج الامتثال، وبناء آليات الحوكمة.
  • استشارات متخصصة: التركيز على قرار واحد واضح، مثل “هل يجب على شركتنا كتابة CLAUDE.md / AGENTS.md أولاً؟” أو تحديد أولويات تصحيح الامتثال للشيفرة القائمة.
  • جلسات للإدارة العليا ومحاضرات عامة: حول أدوات البرمجة بالذكاء الاصطناعي، والحوكمة القائمة على المعايير، وحوكمة المؤسسات، وشركات Frontier Firms.

Artikel ini memberikan kerangka umum, namun implementasi spesifiknya tetap memerlukan perancangan ulang berdasarkan kebutuhan kepatuhan perusahaan, batasan regulasi, kematangan engineering, dan alur kerja yang ada. Untuk kolaborasi, silakan hubungi kami di coach@iaiuse.com.

قراءة موسعة: «منهجية العلامة المرئية v1.0» (تعلم الذكاء الاصطناعي ببطء 187)، والتي تقدم شرحًا منهجيًا لإطار من 7 خطوات للتحول إلى الذكاء الاصطناعي في المؤسسات.

حول هذه السلسلة

«تطوّر هندسة البرمجيات في عصر الذكاء الاصطناعي» هي سلسلة أبحاث موجهة إلى مدراء الاستثمار الرقمي (CIO)، ومدراء البيانات (CDO)، وكبار المسؤولين التقنيين (CTO)، ومسؤولي التحول الرقمي في قطاعات الاتصالات والتمويل والتصنيع والتجارة الإلكترونية. تتكون السلسلة من 18 مقالة، وتركز على كيفية تأثير أدوات البرمجة بالذكاء الاص الاصطناعي، والقيادة بالمعايير، والحوكمة التنظيمية على عمليات تسليم البرمجيات والهياكل التنظيمية والنضج الهندسي.

تتابع السلسلة بشكل مستمر الأبحاث الأكاديمية والمنشورات المتخصصة والتقارير الصناعية، حيث تضم قاعدة بيانات الأبحاث أكثر من 200 مرجع، وتصنف مستوى الأدلة للأحكام الرئيسية، وتميز بوضوح بين الحقائق المثبتة، وادعاءات الشركات المصنعة، والملاحظات الصناعية، واستنتاجات المؤلف.

يتمتع المؤلف بخبرة تقارب 8 سنوات في الاستشارات والتحليل التجاري للمؤسسات الكبيرة، بما في ذلك العمل في IBM على مشاريع في قطاعات التكنولوجيا والمالية والتأمين والتصنيع. كما عمل في الخطوط الأمامية لتطوير منتجات المشغلين والإنترنت وتطبيقات الذكاء الاصطناعي، حيث شارك في تحليل المتطلبات وتصميم المنتجات والتنفيذ عبر الفرق.

هذه السلسلة من الأحكام المتعلقة بالحوكمة القائمة على المعايير، وحوكمة المؤسسات، والهندسة، مستمدة من هذه الممارسات، مع التحقق المتبادل من خلال الأبحاث المنشورة ودراسات الحالة الصناعية. تم إخفاء هوية المحتوى المتعلق بمشاريع محددة؛ وبعض السيناريوهات الصناعية تمثل استنتاجات نموذجية قائمة على المشكلات، والأدلة ذات الصلة مذكورة في المصادر المرجعية في نهاية المقال.

خلف هذه المنصة يوجد في الواقع فريق صغير — أنا وزميل أو زميلان نتعاون معهم على المدى الطويل، نتولى كل منا مسؤولية مجالات بحث أدوات البرمجة بالذكاء الاصطناعي، ودراسات حالات حوكمة المؤسسات، والحوارات الإرشادية. معظم المشاريع التي نذكر فيها أننا “رافقنا الشركات في خوضها” هي مشاريع قمنا بتسليمها معًا. ومع ذلك، لا نذكر أسماء العملاء أو الأفراد بسبب حدود الامتثال، ونُبقي على إخفاء الهوية لإتاحة المجال للتعاون مع زملاء مستقبليين.

المصادر المرجعية (تم التحقق منها جميعًا، مع تحديد مستوى الأدلة لكل بند)

  • CodeRabbit (2025.12). State of AI vs Human Code Generation Report. مشاكل الكود المُولَّد بالذكاء الاصطناعي أعلى بـ1.7 مرة من الكود البشري (10.83 مقابل 6.45 مشكلة/PR)، المنطق/الصحة 1.75×، جودة الكود 1.64×، الأمان 1.57×، معالجة كلمات المرور 1.88×، XSS 2.74×. مستوى الأدلة: أولي. المصدر: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263

  • The Register (2025.12.17). تغطية لتقرير CodeRabbit الكامل: تحليل 470 طلب سحب (PR) مفتوح المصدر، حيث تحتوي طلبات السحب المدعومة بالذكاء الاصطناعي على 10.83 مشكلة مقابل 6.45 في الطلبات البشرية البحتة. مستوى الأدلة: ثانوي. المصدر: نفس الرابط أعلاه

  • CodeRabbit / David Loker (2026.1). “توقعات 2026: فخ السرعة” — عام 2026 هو عام التحول من “سرعة توليد الكود” إلى “جودة الكود والحوكمة”. مستوى الأدلة: ثانوي. المصدر: https://tfir.io/ai-code-quality-2026-guardrails

  • New Relic (2026). تقرير حالة البرمجة بالذكاء الاصطناعي 2026. 78% من الفرق شهدت حوادث أكثر بعد نشر كود مولّد بالذكاء الاصطناعي؛ 62% من القادة التقنيين يعترفون بأن فرقهم “تنشر كود الذكاء الاصطناعي بثقة دون مراجعة”؛ 96% يرون أن المراقبة القابلة للرصد أمر ضروري. مستوى الأدلة: أولي (تقرير من شركة تقنية). المصدر: https://newrelic.com/resources/report/2026-state-of-ai-coding

  • تقرير Microsoft السنوي لمؤشر اتجاهات العمل 2026 (2026.5.5). استطلاع شمل 20,000 عامل في مجال الذكاء الاصطناعي، بتغطية 10 دول؛ 82% من القادة يخططون لتوسيع القوى العاملة باستخدام وكلاء الذكاء الاصطناعي خلال 12-18 شهرًا؛ 81% يتوقعون تكاملًا متوسطًا أو كبيرًا لوكلاء الذكاء الاصطناعي؛ 24% قاموا بنشر على مستوى المؤسسات؛ 49% من محادثات Copilot تدعم العمل المعرفي؛ 58% من مستخدمي الذكاء الاصطناعي حققوا “أشياء لم يكونوا ليتمكنوا من فعلها قبل عام”، وترتفع هذه النسبة إلى 80% بين المحترفين في الطليعة (Frontier Professionals). مستوى الأدلة: المستوى الأول. المصدر: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf

  • نظرة استعادية على السنة المالية 2026 لمايكروسوفت: من التجريب في الذكاء الاصطناعي إلى التحول الحدودي (28 يوليو 2026). قامت EY بنشر Microsoft 365 Copilot لـ 150,000 موظف، مما وفر 2.5 مليون ساعة وحوالي 250 مليون دولار؛ ثم توسعت إلى 400,000 موظف عالميًا، مع تسريع بنسبة 95%، وانخفاض تكاليف العمليات المالية بنسبة 37%، وتقليل سير العمل اليدوي بنسبة تصل إلى 90%. أما Atos فقد نشرت Copilot عبر 56 دولة لـ 56,000 موظف بالإضافة إلى 19,000 وكيل ذكاء اصطناعي، مع مستوى تحكم موحد للهوية والأمان والامتثال والحوكمة. مستوى الأدلة: المستوى الأول (مراجعة رسمية من مايكروسوفت). المصدر: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • التعاون الاستراتيجي بين مجموعة Atos وMicrosoft (2026.6.9). قامت Atos بنشر Microsoft 365 E7 (Frontier Suite) عبر 56 دولة لما يزيد عن 56,000 موظف، بالإضافة إلى 19,000 وكيل ذكاء اصطناعي؛ مع توحيد مستوى التحكم عبر Entra/Defender/Intune/Purview/Agent 365. مستوى الأدلة: المستوى الأول (بيان صحفي مشترك من الطرفين). المصدر: 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 (مصدر مفتوح في سبتمبر 2025، تطوّر في النصف الأول من 2026). بوابة تحكم من 5 مراحل /speckit.constitution → /specify → /plan → /tasks → /implement، مع إضافة /clarify و /analyze؛ مستقل عن النموذج (يعمل مع Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code). مستوى الأدلة: أولي. المصدر: https://github.com/github/spec-kit

  • AWS Kiro (أُطلق في يوليو 2025، تطوّر في النصف الأول من 2026). سير عمل من ثلاث مراحل: المتطلبات ← التصميم ← المهام؛ يطلق الـ spec إجراءات وكيل محددة مسبقًا؛ لا يمكن البدء دون كتابة spec. مستوى الأدلة: أولي. المصدر: https://kiro.dev/

  • OpenAI Codex + AGENTS.md + Skills (2025-2026). تجاوز عدد المستخدمين النشطين أسبوعيًا لـ Codex 5 ملايين في يونيو 2026، منهم 20% من غير المطوّرين؛ AGENTS.md + Skills تشكّل مجموعة تعليمات قابلة للتجميع. مستوى الأدلة: المستوى الأول (إعلان رسمي من OpenAI). المصدر: https://developers.openai.com/codex/skills

  • Claude Code (Anthropic, النصف الأول من 2026). نظام CLAUDE.md + .claude/rules/ + Skills؛ دخل السوق الرسمي لـ Anthropic في فبراير 2026؛ مستودع Skills على GitHub حصد 112 ألف نجمة؛ كشف جولة التمويل G في فبراير 2026 عن إيرادات سنوية بقيمة 2.5 مليار دولار. مستوى الأدلة: المستوى الأول. المصدر: https://code.claude.com/docs/en/claude-directory

  • استطلاع JetBrains AI Pulse (2026.1). شمل أكثر من 10,000 مطوّر محترف حول العالم، بثماني لغات؛ حصل Claude Code على نسبة رضا عملاء (CSAT) بلغت 91% وصافي نقاط الترويج (NPS) 54 (الأعلى في القطاع)؛ بلغت نسبة تبنّي Claude Code في بيئات العمل 18% (ارتفعت 6 أضعاف من 3% خلال 9 أشهر)، و24% في أمريكا الشمالية؛ أما Copilot فبلغت نسبة تبنّيه 29% في بيئات العمل لكنها راكدة؛ وCursor سجّل 18%. مستوى الأدلة: من الدرجة الأولى. المصدر: https://www.jetbrains.com/lp/tools/ai-tools/

  • النشرة الإخبارية لمهندس البراغماتي (Pragmatic Engineer) (2026.2). شملت استطلاعًا لـ 15,000 مطوّر؛ اختار 46% منهم Claude Code كأداة “الأكثر تفضيلًا”، يليه Cursor بنسبة 19%، ثم Copilot بنسبة 9%. مستوى الأدلة: من الدرجة الأولى. المصدر: https://newsletter.pragmaticengineer.com/

  • Alibaba Qoder (2025.8 ← 2026.7). تم إطلاق Qoder من Alibaba في أغسطس 2025؛ وفي 15 مايو 2026، تمت ترقية Qoder 1.0 ليصبح “بيئة تطوير الوكلاء الذاتيين” (Autonomous Agent Development Workbench)؛ ويتضمن سير عمل قائم على المواصفات (Spec-Driven Workflow) + وضع الاستكشاف (Quest Mode) + وضع الخبير (Expert Mode) + مستودع الويكي (RepoWiki)؛ وفي 28 مايو 2026، تم إطلاق Cloud Agents (بيئة تشغيل الوكلاء المُدارة)؛ وفي 21 يوليو 2026، صدر Qoder Security؛ وبلغ عدد المستخدمين العالميين أكثر من 5 ملايين بحلول مايو 2026؛ مع تكامل مع سطر أوامر DingTalk؛ وفي 20 مايو 2026، تم تغيير اسم “通义灵马” إلى Qoder CN. مستوى الأدلة: من الدرجة الأولى. المصدر: https://www.alibabacloud.com/en/marketplace/qoder؛ https://baike.baidu.com/en/item/Qoder/1427525

  • vibecoding.app / thebcms.com / tfir.io (النصف الأول من 2026). أوامر مراحل Spec Kit الخمس، تقييم ومقارنة أدوات SDD، ومنهجية تدوين EARS. مستوى الأدلة: ثانوي (تقييم من طرف ثالث). المصدر: https://vibecoding.app/blog/spec-kit-review؛ https://thebcms.com/blog/spec-driven-development

  • قانون الذكاء الاصطناعي الأوروبي / مدونة الممارسات (التنفيذ الكامل في 2 أغسطس 2026). الموعد النهائي للامتثال لأنظمة الذكاء الاصطناعي عالية المخاطر هو 2 أغسطس 2026؛ بينما مُددت مهلة نماذج الذكاء الاصطناعي العامة الحالية (GPAI) حتى 2 أغسطس 2027؛ والغرامات تصل إلى 35 مليون يورو أو 7% من الإيرادات العالمية؛ وتشمل المواد 9-15 إدارة المخاطر، وحوكمة البيانات، وشفافية التوثيق، والإشراف البشري، والدقة والمتانة. مستوى الأدلة: المستوى الأول (التشريعات + تحليل الامتثال الثانوي). المصدر: https://artificialintelligenceact.eu/code-of-practice-overview؛ https://www.surecloud.com/resource-hub/eu-ai-act-complete-compliance-guide

  • تقرير Qodo عن حالة جودة أكواد الذكاء الاصطناعي (2025). 44% من أسباب المشكلات تعود إلى نقص السياق. مستوى الأدلة: المستوى الثاني (تقرير من بائع). المصدر: https://www.qodo.ai/reports/state-of-ai-code-quality/

慢慢 تعلم الذكاء الاصطناعي 001

الذكاء الاصطناعي في صناعة الاتصالات

في هذا المقال، سنناقش كيف يمكن للذكاء الاصطناعي أن يساعد صناعة الاتصالات في تحسين تجربة العملاء وتحقيق أهدافها. سنستخدم例ًا من شركة AT&T، التي تستخدم الذكاء الاصطناعي لتحسين تجربة العملاء وتحقيق أهدافها.

الذكاء الاصطناعي في تحليل البيانات

الذكاء الاصطناعي يمكن أن يساعد في تحليل البيانات الكبيرة التي تنتجها صناعة الاتصالات. يمكن للذكاء الاصطناعي تحليل هذه البيانات وتحديد الاتجاهات والتحليلات التي يمكن أن تساعد في تحسين تجربة العملاء.

الذكاء الاصطناعي في تحسين تجربة العملاء

الذكاء الاصطناعي يمكن أن يساعد في تحسين تجربة العملاء من خلال تحليل البيانات وتحديد الاتجاهات والتحليلات التي يمكن أن تساعد في تحسين تجربة العملاء.

الذكاء الاصطناعي في تحقيق أهداف

الذكاء الاصطناعي يمكن أن يساعد في تحقيق أهداف صناعة الاتصالات من خلال تحليل البيانات وتحديد الاتجاهات والتحليلات التي يمكن أن تساعد في تحقيق أهداف.

الذكاء الاصطناعي في صناعة الاتصالات

الذكاء الاصطناعي يمكن أن يساعد في تحسين تجربة العملاء وتحقيق أهداف صناعة الاتصالات من خلال تحليل البيانات وتحديد الاتجاهات والتحليلات التي يمكن أن تساعد في تحسين تجربة العملاء وتحقيق أهداف.

مثال من شركة AT&T

شركة AT&T تستخدم الذكاء الاصطناعي لتحسين تجربة العملاء وتحقيق أهدافها. يمكن للذكاء الاصطناعي تحليل البيانات وتحديد الاتجاهات والتحليلات التي يمكن أن تساعد في تحسين تجربة العملاء وتحقيق أهداف.

الذكاء الاصطناعي في صناعة الاتصالات

الذكاء الاصطناعي يمكن أن يساعد في تحسين تجربة العملاء وتحقيق أهداف صناعة الاتصالات من خلال تحليل البيانات وتحديد الاتجاهات والتحليلات التي يمكن أن تساعد في تحسين تجربة العملاء وتحقيق أهداف.

مصادر

  • [1] “الذكاء الاصطناعي في صناعة الاتصالات”، شركة AT&T.
  • [2] “الذكاء الاصطناعي في تحليل البيانات”، شركة Verizon.
  • [3] “الذكاء الاصطناعي في تحسين تجربة العملاء”، شركة NTT.

المصادر

  • [1] “الذكاء الاصطناعي في صناعة الاتصالات”، شركة AT&T.
  • [2] “الذكاء الاصطناعي في تحليل البيانات”، شركة Verizon.
  • [3] “الذكاء الاصطناعي في تحسين تجربة العملاء”، شركة NTT.
]]> عيوب كود AI 1.7 ضعف وثغراته 2.74 ضعف — لا يرى قواعدك. منصات Spec Kit وKiro وCodex وClaude Code وQoder تتجه 2026 H1 لكتابة CLAUDE.md. Spec-Driven Development: Writing Specs Is the Highest-ROI Engineering Move in the AI Era — Learn AI Slowly 177 https://iaiuse.com/en/posts/spec-driven-development-writing-specs-is-the-highest-roi-engineering-move-in-the-ai-era-ai-era-software-engineering-transformation 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z Your Biggest Mistake Isn’t Not Buying Tools, It’s Not Writing CLAUDE.md

A regional carrier’s CIO complained to me: “We’ve bought AI tools, deployed models, and even trained our people, but by the end of the first half of 2026, our delivery cycle hasn’t changed much. The head of the core systems team was even more blunt: ‘The AI-generated code works, but we have to rewrite it every time – it doesn’t understand our bank’s rules, it doesn’t understand the regulatory requirements, and it doesn’t know how to integrate with our 30-year-old legacy system.’”

The issue isn’t that AI isn’t powerful enough, it’s that you haven’t written down the rules. CodeRabbit’s analysis of 470 open-source PRs in December 2025 yielded a widely-cited statistic: AI-assisted PRs averaged 10.83 issues, while purely human PRs averaged 6.45 - 1.7 times more, with 70% more bugs than human-written code. By 2026, the story hadn’t changed: New Relic’s 2026 State of AI Coding Report found that 78% of teams reported more incidents after deploying AI-generated code, and 62% of technical leaders admitted their teams “confidently deploy AI code without reviewing it line-by-line” (New Relic Official Report 2026, 0.866 score, primary source). Both datasets are saying the same thing - AI isn’t lacking in capability, it’s lacking context. At this point in August 2026, all narratives about “accelerating AI transformation” need to be viewed in light of this:

CampProgress (2026 H1)Counterexample (2026 H1)
EYRolled out Microsoft 365 Copilot to 150,000 employees, saving 2.5 million hours / $250 million; expanding to 400,000 global employeesAcknowledges 95% acceleration and 37% reduction in financial operations costs, attributing success to “regulatory compliance first”
AtosDeployed to 54 countries / 56,000 employees; running 19,000 AI agents with unified identity, security, compliance, and governance control planeEmphasizes “getting Agent 365’s governance capabilities online before scaling”
Microsoft2026 Work Trend Index: 82% of leaders plan to use AI agents to augment workforce within 12-18 monthsSimultaneously acknowledges “organizational change lags behind individual adoption” – a core paradox in the Frontier Firm concept

来源：Microsoft FY26 retrospective 2026.7.28；Microsoft 2026 Work Trend Index Annual Report 2026.5.5；New Relic 2026 State of AI Coding Report。

The following two comparisons illustrate one thing: without standards, scaling up means multiplying risks by N. The “speed” of EY, Atos, and Microsoft is not about the speed of models, but about “organizations answering how to use AI first.” This is the context in which Spec-Driven Development (SDD) has become mainstream in 2026 H1 - not because engineers prefer documentation, but because not writing specifications is no longer viable in environments with 19,000 agents.

This article clarifies three things:

  1. Why AI code defects are more severe than human-written code by over 1.7 times;
  2. How GitHub, AWS, OpenAI, Anthropic, and Alibaba have converged on the same paradigm in 2026 H1 - using documentation to constrain AI behavior;
  3. Why SDD is an organizational capability, not a tool choice, and the three stages of implementation in 2026 H1.
AI code vs human code: defect distribution (470 open-source PRs analyzed) CodeRabbit 2025.12 report | all numbers are AI/human multiples (baseline 1.0)

Bar length = AI defects as multiple of human; baseline 1.0× = human level

Baseline 1.0×

Total issues

1.7×
AI 10.83 vs human 6.45 / PR

Logic / correctness errors

1.75×

Code quality / maintainability

1.64×

Security findings (combined)

1.57×

Improper password handling

1.88×

XSS vulnerabilities

2.74×
↑ Highest

Unconstrained AI code exceeds human on every dimension
Finance/telecom = compliance reconciliation, password management, sensitive field encryption — AI misses all

1. AI Defect Rates: A Contextual Problem, Not a Model Problem

A statement from CodeRabbit’s report has been frequently quoted: “AI lacks local business logic: models infer code patterns statistically, rather than semantically. Without strict constraints, they miss system rules internalized by seasoned engineers.” This statement explains why CodeRabbit, an AI coding platform specializing in AI code review, was among the first to notice this data. They review thousands of PRs daily and see the output of AI-generated code.

The most critical finding is not the total number, but the distribution:

  • Logic/Correctness: +75%: Business logic errors, dependency errors, control flow errors, and configuration errors—these issues may not be exposed in testing but can cause accidents in production environments.
  • Code Quality: +64%: Inconsistent naming, unclear structure, and project pattern violations—this is the “largest difference category.” Seasoned engineers can immediately spot “this isn’t how we write code here.”
  • Security: +57% (XSS highest at 2.74×): Inadequate password handling (1.88×), insecure object references (1.91×), sensitive information disclosure, and insecure deserialization (1.82×)—in the finance industry, this isn’t about “can it be used,” but “can it be released.”

The issue isn’t that AI isn’t powerful enough. It’s that it can’t see.

To return to this CIO’s real pain point, here are three concrete AI failures in critical financial systems:

First, AI can’t see 30 years of reconciliation logic. A bank’s risk-control rules live in core system stored procedures—written 30 years ago, and no one remembers them in full. AI-generated code logic looks fine, but in production it triggers that forgotten reconciliation check and fails an entire batch of transactions.

Second, AI can’t see regulatory constraints. Passwords must go through a key management system, sensitive fields must be encrypted at rest, logs cannot print customer information—these are hard regulatory constraints written into internal policies. AI doesn’t know them; the code it writes runs, but won’t pass compliance review.

Third, AI can’t see your technical debt. That 30-year-old host system uses its own interface protocol, and the documentation is long gone. AI writes code to generic RESTful standards, only to discover in production that the interfaces don’t match—two weeks of rework.

Back to New Relic’s other numbers: 62% of teams “confidently ship without review” AI code, and 78% report more incidents after deployment. Put together, these two numbers say one thing—the defect rate of AI code itself isn’t the problem; “I don’t know what defects my AI code has” is the problem.

Typical scenario: a joint-stock bank introduces AI-assisted development for the risk-control module of its core system. Within three months, the compliance review rejection rate climbs significantly—the top reasons are password handling, sensitive field encryption, log compliance, and other internal rules. All these rules live in internal documents, but AI can’t see them. The team then writes the core rules into a CLAUDE.md file, and the rejection rate drops noticeably.

2. The Five Major Platforms in 2026 H1 — Converging on “Spec-Driven”

GitHub released Spec Kit in July 2025; in early 2026, AWS Kiro, OpenAI Codex, and Anthropic Claude Code completed the lineup; in May 2026, Alibaba Qoder wrote “Spec-Driven Workflow” into its product positioning. All five platforms converged on the same paradigm in 2026 H1—using documentation to constrain AI behavior. This isn’t any one company’s invention; it’s the industry’s collective response to the “AI code quality crisis.”

Five-platform compliance-driven roadmap (2025-2026 H1) GitHub Spec Kit Open Source 2025.9 constitution.md Five-stage gating: constitution → specify → plan → tasks → implement Model-agnostic, supports 8+ agents Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md Three-stage workflow: Requirements → Design → Tasks Spec-driven, embedded in IDE workflow Hook-triggered auto agents Compliance/audit hooks pre-installed Won't start without a spec OpenAI Codex 2025-2026 AGENTS.md + Skills system Composable instruction sets Team-level shared config 5M+ weekly active (2026.6) Non-developers account for 20% From coding to general-purpose agents Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + Skills (Official Marketplace 2026.2) + MCP Ecosystem CSAT 91% / NPS 54 $2.5B ARR（2026.2） 112K stars on GitHub Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Quest Mode Autonomous Execution + Expert Mode Team + RepoWiki Context 5M+ Global Users (2026.5) 2026.7.21 Qoder Security DingTalk CLI Integrated Shared Paradigm: Explicitly document "how we collaborate with AI" and place it in the repo Have all people and all AI agents work against the same spec—this is the essence of spec-driven development

GitHub Spec Kit: a reference implementation with five-stage gating. Open-sourced in September 2025, by H1 2026 it has become the industry’s reference implementation. 5 core commands + 2 supplements: /speckit.constitution (Non-Negotiable Principles), /speckit.specify (what and why), /speckit.plan (how to change), /speckit.tasks (task breakdown), /speckit.implement (execution), plus /clarify and /analyze. The key design is model-agnostic: the same spec/plan/tasks files are not bound to any specific execution agent and can be picked up by Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf, or Qwen Code. That’s what makes it an “organizational-level SDD protocol,” not a GitHub-exclusive product (vibecoding.app review, June 2026, 0.816 score, secondary source).

AWS Kiro: spec-driven embedded in the IDE. Launched in July 2025, AWS Kiro evolved into a full-fledged Agent IDE by H1 2026. Its workflow runs in three phases: requirements → design → tasks. What sets Kiro apart from Spec Kit is its “hooks” — Kiro’s spec files can trigger predefined agent actions and weave compliance, audit, and deployment steps that require external systems into the workflow. If you want to enforce spec-writing in your team, pick Kiro — without a spec, Kiro simply won’t start (AWS Kiro, July 2025; Kiro.dev documentation, 2026).

OpenAI Codex: AGENTS.md + composable Skills. Between 2025 and 2026, OpenAI pushed AGENTS.md to the center of its ecosystem. Skills are the key H1 2026 extension: they let you pre-assemble workflows — “read an Excel file,” “generate SQL,” “run a data migration” — and invoke them like Lego blocks. By June 2026, Codex had passed 5 million weekly active users, 20% of whom are non-developers — a frequently overlooked signal that spec-driven development is no longer just for engineering teams but for the whole enterprise. Product, operations, and risk-management teams now write their own AGENTS.md files (OpenAI announcement, June 2, 2026; thebcms.com review, 2026, 0.801 score).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic calls its project instruction file CLAUDE.md (entered the official marketplace in February 2026), .claude/rules/ (rules layered by directory), and Skills (shareable workflows). Claude Code is the highest developer-satisfaction tool in H1 2026 — the JetBrains 2026.1 survey gives it CSAT 91% and NPS 54, a number corroborated by two independent studies (Pragmatic Engineer, February 2026). That’s the industry’s best score in the AI coding assistant category (uvik.net, May 2026, 0.956 score, aggregation of primary sources). Claude Code went from zero to $2.5 billion annualized revenue in nine months (Anthropic Series G, February 2026), with 112,000 stars on GitHub (Skills repo) — developers vote with their feet, and that vote is evidence of the real value of a rules-driven approach.

Alibaba Qoder: spec-driven for the Chinese market. Launched in August 2025, Qoder went to version 1.0 on May 15, 2026, officially repositioning from “AI IDE” to “Autonomous Agent Development Workbench.” Its Spec-Driven Workflow shipped alongside Quest Mode (autonomous multi-file tasks), Expert Mode (parallel execution by expert teams), and RepoWiki (repository knowledge graph). On May 28, 2026 came Cloud Agents (fully managed agent runtime), followed on July 21 by Qoder Security (compliance and security capabilities), and a Mobile version (Android/iOS/HarmonyOS) the same month. By May 2026 Qoder had more than 5 million global users, and Microsoft Teams CLI lists it among supported agent execution environments (Yahoo Finance 2025; Alibaba Cloud Official 2026; Baidu Baike, July 2026).

Common Paradigm: Explicitly document “how we collaborate with AI” and store it in a repository, allowing all team members and AI agents to work with the same set of guidelines. Although the implementation details of the five platforms differ (file names, stages, hook mechanisms), their goals are identical.

Why did this happen in H1 2026? The AI capability threshold has been crossed - Claude Code autonomous agents, Codex multi-agent parallelism, and Cursor multi-file refactoring have made AI more than just a “completion tool”, it’s a “colleague”. If you can provide an onboarding document for a new colleague, you should also be able to provide one for AI.

Three: Specification-Driven is an Organizational Capability, Not a Tool Choice

This is the most important point for decision-makers. Specification-driven is not about choosing tools, but defining “how our organization collaborates with AI”. Whether you choose GitHub Spec Kit or Claude Code is irrelevant; what matters is whether you have documented your specifications, stored them in a repository, and ensured that all team members and AI agents work with them.

Without this, even the best tools will only enable your team to create more debt at a faster pace.

Viewed through the lens of scaled deployment in H1 2026, the evidence gets even stronger. In its FY26 retrospective published in July 2026, Microsoft framed the EY and Atos cases as “Frontier Firm” templates—not because the models were new, but because both companies had already answered the “how do we actually use AI” question before scaling:

EY: Governance first, scale pays off. Between 2024 and 2025, EY rolled out Microsoft 365 Copilot to 150,000 employees, saving 2.5 million hours and roughly $250 million. The prerequisite: an AI governance framework built before deployment. EY used Power Platform, Copilot Studio, Azure, Foundry, and Fabric to create a unified toolchain, embedding compliance, governance, and audit into a single foundation. That’s what enabled the subsequent 95% speedups, 37% reduction in finance operations costs, and up to 90% reduction in manual workflows. As EY’s vice president put it bluntly at the 2026 AI Tour: “We didn’t roll out AI and then bolt on governance—we built governance first, then scaled AI.”

Atos: A Unified Control Plane for 19,000 Agents. Atos is among the first organizations globally to deploy Microsoft 365 E7 (Frontier Suite), rolling out Copilot to 56,000 employees across 54 countries. They are simultaneously running 19,000 AI agents—spanning internal IT, business units, and client projects—all built on Foundry and Copilot Studio. The key to Atos’s success is a “single control plane”: Entra (identity) + Defender (security) + Intune (device management) + Purview (compliance) + Agent 365 (agent governance), all bound together. This integrated approach, when mapped to the financial sector, translates to a governance architecture—covering security assessments, data cross-border compliance, algorithm filing, auditing, and model governance—rather than just a standalone AI tool.

Microsoft’s Own “Organizational Change Paradox.” In its 2026 Work Trend Index report, Microsoft itself acknowledged a key tension: “the pace of organizational change is lagging behind individual adoption.” Among the 20,000 AI users they surveyed, 82% of leaders plan to scale their workforce with AI agents within 12–18 months, but only 24% have completed enterprise-level deployment. 81% of leaders expect AI agents to be moderately or heavily integrated into their AI strategy — yet again, only 24% have actually done so. This means the vast majority of organizations face a 12-to-18-month gap between “getting ready” and “getting it done.” How that gap gets closed is where governance-driven discipline becomes the primary anchor.

Source: Microsoft FY26 retrospective, July 28, 2026; Microsoft 2026 Work Trend Index Annual Report, May 5, 2026 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, primary PDF source); Futurum Group analysis, January 26, 2026 (secondary source).

Takeaway #1: Investing in governance is high-ROI.

CodeRabbit’s data gives us a clear basis for ROI calculation: AI code issue rate is roughly 1.7x, and security vulnerabilities are reduced by 2.74x. What this means:

  • Less rework (in financial services, one compliance review rework alone costs 2–4 weeks)
  • Fewer security incidents (regulatory fines and reputational damage from a single data breach)
  • Lower maintenance costs (a 40% reduction in technical debt is a commonly cited figure)

Writing a CLAUDE.md/AGENTS.md project specification is the highest-ROI engineering move in the AI era. EY’s case provides a real-world conversion—150,000 employees equipped with Copilot, saving $250 million. Note that EY’s savings didn’t come from the tool being “powerful”—they came from the spec “unlocking the tool’s value.”

Insight Two: Bake the spec into organizational processes, not individual habits.

If the spec lives only in a senior engineer’s head, it’s lost the moment that person leaves. It must be embedded in:

  • Repository documentation (AGENTS.md / CLAUDE.md / constitution.md)
  • CI gates (automated checks for spec compliance)
  • Team-shared configurations (Skills system makes it usable across the whole team)

Let Governance Be an Organizational Asset, Not an Individual Skill

This matters especially in financial services—your compliance requirements, security rules, and business rules are organizational assets, not one engineer’s “experience.” Atos runs 19,000 agents across 54 countries because governance isn’t “someone knows how to do it”—it’s “the system enforces it.”

Insight Three: Gating matters more than speed.

GitHub Spec Kit’s five-stage gating (constitution → specify → plan → tasks → implement), Claude Code’s “don’t write code before tests fail,” and Kiro’s “can’t start without a spec”—they’re all doing the same thing: putting a brake between AI and the final output. Every step produces a reviewable artifact (spec.md, plan.md, tasks.md) that can be rejected or revised before code is generated.

The more autonomous the AI, the more it needs gating. In financial services, the Change Advisory Board (Change Advisory Board (CAB)), algorithm filing requirements, and security compliance assessments are all gates before production. AI code needs the same kind of gating, just in a different form. The 62% of teams in New Relic’s 2026 report who “confidently ship without review” are paying for that confidence with a higher incident rate (78%).

Three Phases of Financial Industry Spec Implementation (2026 H1 Practical Edition) Phase 1: Inventory Rules 2-4 Weeks | Most time-consuming, highest ROI Compliance Requirements Checklist (MLPS/Data Export/Filing) Security Rules (Passwords/Encryption/Logs) Business rules (risk control/transactions/billing) Technical constraints (legacy interfaces/version limits) Vendor governance (contracts/audits/liability) Consolidate scattered rules Into structured documentation Phase 2: Land in repository 1-2 weeks | Into repo, AI auto-loads CLAUDE.md / AGENTS.md constitution.md Skills definition (shareable workflows) Gate process design (five phases) .claude/rules/ (layered rules) Put rules into repo, AI auto-loads Phase 3: Institutionalize Ongoing | From tool to org capability CI gates (automated review) Team Shared Configuration (Skills) Regular Update Mechanism (Quarterly Review) Metrics (Defect Rate / Compliance Pass Rate) Agent Governance (Agent 365 Level 1) Standards Become Organizational Assets, Not Dependent on Individuals

Phase 1 Takes the Most Time but Has the Highest ROI
Most Financial Organizations’ Rules Are Scattered Across Documents/Emails/Brains; the First Cleanup Is a 3-8 Week Investment

Phase 3: Real-World Implementation in H1 2026

Using the financial industry as an example, this three-phase path also applies to other heavily regulated sectors. EY and Atos’s H1 2026 practices map neatly onto these three phases.

Phase 1: Inventory Your Rules (2–4 weeks).

This phase takes the most time but delivers the highest ROI. The goal is to surface every rule scattered across your organization:

  • Compliance requirements: For financial institutions, the minimum baseline = ISO 27001 certification + GDPR/UK GDPR compliance + EU AI Act high-risk AI registration (if serving EU clients) — if any one is missing, don’t roll out AI. Above that, you have regulatory reporting rules, customer data protection, cross-border data transfer restrictions, and rules on which data AI is even allowed to see.
  • Security rules: Password management, encryption standards, sensitive-field handling, logging requirements.
  • Business rules: Risk-control thresholds, claims eligibility, transaction limits, billing logic.
  • Technical constraints: Legacy system interfaces, database naming conventions, framework version limits.
  • Vendor governance: How to contractually require vendors to follow your standards, and how to audit their AI usage.

A typical scenario: during the inventory phase, a securities firm discovers that its rules are scattered across countless Word documents, JIRA wikis, personal emails, and Excel spreadsheets—only after consolidating everything does a structured rule list emerge. Atos takes a more systematic approach: they split rules directly into five categories—compliance, security, business, technical, and vendor—each with its own governance workflow, all wired into the Agent 365 control plane.

This isn’t a technical exercise; it’s an organizational one. You have to bring compliance, security, and business teams to the same table and write down rules everyone agrees on. The first time you do this, a financial organization typically needs 3–8 weeks—but what you get is a permanent organizational asset.

Phase 2: Land it in the repo (1–2 weeks).

Take the rules from Phase 1, write them up as documentation, and commit them to the repository. GitHub Spec Kit uses constitution.md, Claude Code uses CLAUDE.md, OpenAI Codex uses AGENTS.md, and Alibaba Qoder uses Spec Workflow. The file names differ, but the goal is the same—make the AI load them the moment it opens the repo.

Structure Recommendations (Mainstream Form in 2026 H1):

  • Project Overview: What this system does and who it serves
  • Non-Negotiable Principles: Security red lines, compliance red lines, business red lines
  • Tech Stack and Constraints: Which frameworks, databases, and interface standards to use
  • Code Standards: Naming conventions, directory structure, and minimum test coverage requirements (no mandatory TDD cadence—just spell out coverage thresholds, must-test paths, and forbidden paths; TDD is an optional organizational rhythm, not a hard requirement driven by standards)
  • Business Rules: Risk control logic, transaction rules, billing rules
  • Compliance Requirements: MLPS (等保, Multi-Level Protection Scheme), cross-border data transfer, regulatory reporting, and whether AI-generated algorithms require filing
  • AI Usage Guidelines: Which scenarios can use AI, which scenarios require mandatory human review, and cross-border data rules
  • Vendor Governance: Contract terms, audit mechanisms, and responsibility allocation

Appendix: CLAUDE.md Financial Edition Skeleton (~200 lines, ready to fork and adapt)

Below is a CLAUDE.md skeleton for a joint-stock bank’s core system overhaul, organized in the order of “Non-Negotiable Principles → Compliance Requirements → AI Usage Guidelines → Business Rules → Engineering Constraints.” Your company doesn’t need to start from scratch—just fill in the blanks with your specific rules.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
# CLAUDE.md — <System Name> AI Collaboration Standards

> Scope: <System Name> v<Version>, all AI agents (Claude Code / Cursor / Copilot / Codex)
> working in this repository must comply with these standards. Maintained by the <Governance Committee>,
> reviewed quarterly.
> Last updated: YYYY-MM-DD

## 1. Project Overview
- **Business Positioning**: Core system name / customer segments / main transaction types
- **Critical Chain**: Transaction → Risk Control → Clearing → Reconciliation → Regulatory Reporting
- **Outage Window**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (no changes permitted)
- **Core Dependencies**: Upstream <System>, Downstream <System>, Regulatory Reporting Platform

## 2. Non-Negotiable Principles (Red Lines — any violation = merge refused)

### 2.1 Security Red Lines
- Passwords, keys, and tokens must always go through KMS (Key Management Service) — **no hardcoding**, **no logging**
- Customer sensitive fields (national ID / card number / CVV / phone number) **must be encrypted at rest**; plaintext is forbidden in the database
- Logs must never contain: full national ID, full card number, plaintext passwords, customer name + phone number combinations
- External API calls must go through the API Gateway; direct connections are forbidden

### 2.2 Compliance Red Lines
- AI-generated code that involves customer data access must annotate "data access: <field>" in the PR description
- Cross-border data transfer is forbidden; **all outbound data must go through the Cross-border Data Transfer Assessment process** (contact Compliance)
- Algorithmic decisions (credit / insurance pricing / anti-fraud) must retain a human review path
- Model changes must go through Algorithm Filing; the filing number must be cited in the PR description

### 2.3 Business Red Lines
- Risk control threshold changes require dual signature from the risk control lead and the business lead
- Operations involving customer funds must have idempotency design + failure rollback
- Transaction limits, fees, and product parameters must be managed via the parameter management platform; no hardcoding in code

## 3. Tech Stack and Constraints
- **Languages**: Java 17 (core) / Kotlin (new modules) / SQL (database)
- **Framework**: Spring Boot 3.x + Spring Cloud Alibaba
- **Database**: OceanBase 4.x (MySQL-compatible mode); **foreign keys are forbidden**
- **Interface Standards**: gRPC internally; OpenAPI 3.0 for external interfaces; RESTful only for admin interfaces
- **Naming Conventions**: Java classes PascalCase, methods camelCase, constants UPPER_SNAKE; tables `t_<domain>_<entity>`; indexes `idx_<table>_<column>_<order>`
- **Package Structure**: `com.<company>.<domain>.<sub-domain>.<layer>` (e.g., `com.bank.pay.tx.core.service`)

## 4. Code Standards
- **Minimum Test Coverage**: critical chain ≥ 80%, utilities ≥ 60%; all new code PRs must include tests
- **Required Test Paths**: all controllers must have integration tests (including failure paths); all enum branches must have unit tests
- **Forbidden Paths**: modifying the `<Legacy Modules>` directory is forbidden — build an adapter layer first
- **Dependency Management**: any new third-party dependency must go through SCA scan + security approval

## 5. Business Rules (by Domain)
### 5.1 Transactions
- Single-transaction limit: <Amount>; daily limit: <Amount>; any excess goes through manual approval
- Transaction time window: <HH:MM> ~ <HH:MM>
- Duplicate transaction detection: same <field> within <time window> = duplicate

### 5.2 Risk Control
- Blacklist matching priority: internal blacklist → regulator-supplied list → judicial freeze
- Anti-fraud model output threshold: <Score>; exceeding requires mandatory human secondary review

### 5.3 Billing
- Any fee change must include a version number + effective date
- Historical orders are billed at the rate in effect on the effective date; no retroactive adjustment

## 6. Compliance Requirements
- MLPS Level 3: <Regulator>, <Next Assessment Date>
- Cross-border Data Transfer Assessment: scope (only cross-border business modules)
- Algorithm Filing: scope (credit / insurance pricing and other critical algorithms), filing number `<Registration No.>`
- Regulatory Reporting: <CBIRC / People's Bank of China> field mapping table at `<path>`

## 7. AI Usage Standards
- **Scenarios where AI may be used**: CRUD boilerplate, unit test generation, document drafts, SQL optimization suggestions
- **Scenarios requiring mandatory human review**: risk control logic, billing rules, permission control, encryption/decryption, cross-border data
- **Scenarios where AI may not act alone**: Change Advisory Board (CAB) approval materials, production change execution, incident response
- **Cross-border Data Rules**: training data / prompts / output logs never leave the country; localized deployment versions (<Vendor>) are preferred
- **Audit Requirements**: all AI-generated code must be tagged "AI assistance: <tool name>" in the PR description

## 8. Vendor Governance
- **Vendor Admission**: must provide SOC 2 / ISO 27001 reports; AI models must provide a model card
- **Contract Terms**: data ownership, model explainability, exit clauses, audit rights
- **Audit Mechanism**: quarterly AI usage audits for vendors; monthly audits for high-risk vendors

## 9. Governance and Updates
- **Owner**: <Governance Committee> (compliance + security + architecture + business)
- **Update Frequency**: quarterly review; emergency changes go through the fast lane (double signature + 24h announcement)
- **Change Log**: see `CLAUDE_CHANGELOG.md`
- **Violation Handling**: 1st violation = warning + mandatory training; 2nd violation = suspension of AI tool usage; 3rd violation = revocation of permissions

This skeleton is not a “standard answer” — it’s a “fill-in-the-blank template.” What matters more than how much you write is what goes into each slot. The blank spaces reveal the parts your company hasn’t thought through yet.

A typical example: one joint-stock bank’s CLAUDE.md defines a dedicated password-handling rule — any AI-generated code involving passwords must call the internal key management API, and hardcoding is prohibited. Rules like this account for a large share of compliance review rejections.

An important new field in 2026 H1 is Skills/workflow definitions — not just documentation, but toolchains that AI can actually invoke. Claude Code’s Skills system (listed on Anthropic’s official marketplace in February 2026, 112K stars on GitHub) turns routine tasks like “read an Excel sheet,” “generate SQL,” and “run a data migration” into shareable workflows. This is the key evolution of spec-driven development in 2026 H1: specs are not just constraints — they are executable workflows.

Phase 3: Institutionalization (ongoing).

Writing a spec is not the finish line—it’s the starting point. You have to turn it into part of your organizational process:

  • CI gating: Automatically check code against the spec (e.g., detect hardcoded passwords, unencrypted sensitive fields)
  • Team-shared configs: Use the Skills system so the whole team works from the same spec
  • Regular update cadence: When rules change, the spec changes with them (quarterly review)
  • Metrics and feedback: Track defect rates in AI-generated code, compliance review pass rates, rework rates
  • Agent governance: Extend human governance to AI agents—what Atos is doing with Agent 365 is making this “system-level” rather than “individual-level”

Both EY and Atos made Phase 3 about “organizational capability” in H1 2026. EY’s 2.5 million hours saved came down to getting Phase 1 and Phase 3 right—Phase 2 was just translating rules into documents AI could read.

V. The Heavily Regulated Variant: Three Engineering Approaches to Embedding Compliance

For heavily regulated industries like finance, telecom, and healthcare, spec-driven adoption has one extra hurdle compared to general industries—compliance is not a bolt-on to the process; it’s built into the code. The three approaches below are compliance-embedding patterns validated in H1 2026. CIOs and digital transformation leads can reference them directly when designing their organizations.

5.1 Embedding Compliance Representatives in Stream Teams: Making Compliance “Present” Rather Than “Approval”

The traditional approach: business teams write code, compliance teams review afterward—by the time issues are found in review, the code has already been in production for two weeks, and rework costs 2–4 weeks. The core problem is that compliance sits at the end of the pipeline.

The new approach: embed a compliance representative in every stream-aligned team, structured as a dual reporting line—solid line to the compliance department, dotted line to the business team. Concretely:

  • Headcount: One compliance representative per 6–8 stream teams, belonging to the compliance department but physically seated with the business team—not a “secondment” where they show up occasionally
  • Dotted-line KPIs: 50% of the compliance representative’s performance weight is tied to the business team’s “compliance defect rate” and “first-pass review approval rate,” not just the compliance department’s “audit coverage”
  • Shift-left engagement: Compliance representatives join daily stand-ups (once a week is sufficient), participate in PR reviews, and AI-generated code must pass the compliance representative before merge—not be caught and patched after the fact
  • Tooling: Compliance representatives invoke compliance checklists via Skills rather than manually walking through each item line by line

Typical scenario: In H1 2026, a national joint-stock bank piloted three stream-aligned teams with embedded compliance representatives, cutting the AI code compliance rejection rate from 35% to 8% — the key wasn’t that compliance became “stricter,” but that it became “earlier.” The crux of this approach is that the compliance representatives’ dotted-line incentives must align with business goals — if their KPIs still only reflect tasks handed down by the compliance department, the embedding is doomed.

5.2 Compliance as an Enabling Team: Turning Constraints into Affordances

The traditional approach: compliance acts as a “gatekeeper,” and business teams see it as a “troublemaker.” It’s a zero-sum game.

The new approach: the compliance team is restructured along Team Topologies’ enabling team model — it doesn’t write code or review pull requests directly, but provides three things that let business teams achieve “self-service compliance”:

  1. Compliance checks embedded in the CI pipeline: Turn high-frequency compliance pain points—hardcoded passwords, plaintext sensitive fields, cross-border data transfers, algorithmic decision points—into mandatory gates in GitHub Actions / GitLab CI. When a business team opens a PR, automated checks run immediately, and non-compliant code fails outright—no need for a compliance officer to manually review each change.

  2. Regulatory requirements as affordances (environmental, context-aware constraints): For example, when a developer builds a feature that touches customer data, an IDE plugin pops up a hint like “This field should call KMS”; when writing logs, the system automatically detects whether sensitive information is included and raises an alert. Compliance becomes something that “happens naturally during development,” not something you’re told you violated at release time.

  3. Shared Skills library + compliance training: The compliance team maintains a set of “compliance Skills” that new hires and cross-team transfers can invoke directly—turning compliance knowledge from “documentation” into “executable tooling.”

A typical case: a regional commercial bank rolled out CI compliance gates plus IDE compliance hints in H1 2026, cutting the average per-review time for AI-assisted code compliance checks from 45 minutes to 8 minutes. The real win isn’t that compliance “reviews got faster”—it’s that AI-generated code “doesn’t make mistakes in the first place.”

5.3 Dual-Speed Compliance: Matching Regulatory Rigor to Business Velocity

One final nuance: compliance shouldn’t be a one-size-fits-all approach. Split your rules into two tiers by risk level:

  • High-risk rules (involving customer funds / algorithmic decisions / cross-border data / critical security baselines) go through strict gating: mandatory human review + AI second confirmation + Change Advisory Board (Change Advisory Board (CAB)) filing
  • Low-risk rules (CRUD boilerplate / utility code / documentation generation) go through self-service gating: CI auto-checks are sufficient, no human review required

Atos’s Agent 365 control plane is essentially this tiering—different levels of agents bind to different governance requirements. When you tier compliance rules by risk, business teams stop feeling like “compliance is blocking me at every turn.”

The takeaway from all three points: embedding compliance isn’t about adding another process step—it’s about redesigning the structure and incentives of your delivery teams. If your compliance department is still stuck in “post-hoc review” mode, spec-driven adoption will hit a wall at the hardest stage: institutionalization. Compliance needs to transform first, and only then can spec-driven development run smoothly for business teams.

6. Questions You Might Be Asking

“We already have coding standards—how is this different?”

Coding standards govern how you write code; spec-driven development governs how you collaborate with AI. Coding standards don’t cover: business rules, compliance requirements, or AI usage policies. Spec-driven development makes the entire human-AI collaboration workflow explicit—it’s not a code style guide.

“Will writing specifications slow down development?”

In the short term, yes. In the long term, no. CodeRabbit’s data gives a clear answer: unconstrained AI code carries roughly 1.7x higher defect risk and 2.74x more security vulnerabilities. In financial services, a single compliance review rework costs 2–4 weeks—skip one rework and you’ve bought yourself a month’s worth of spec writing. EY’s $250 million savings is real-world proof that this pays off when done as an organizational capability.

“What if our team has no one who knows how to write specs?”

You don’t need to start from scratch. GitHub Spec Kit, Claude Code Superpowers, and AWS Kiro all ship with templates. All you need to do is fill in the rules specific to your organization—and most of those are compliance and security rules that your compliance and security teams have already written down. They just haven’t been put somewhere AI can actually see them.

“There are so many AI tools out there—which one should we pick?”

It doesn’t matter. Pick what you’re already using. The spec drives, not the tool—CLAUDE.md works in Claude Code, Cursor, and Codex; AGENTS.md runs in the OpenAI ecosystem; constitution.md is model-agnostic. The point is writing the spec, not switching tools. EY is rolling out across the Microsoft ecosystem, Atos is rolling out across the Microsoft ecosystem—the tool choice is just surface-level; the unified governance architecture is what matters underneath.

“The EU AI Act fully takes effect in August 2026—does that affect us?”

Yes. The EU AI Act enters full application on August 2, 2026, with mandatory compliance requirements for high-risk AI systems—including credit scoring, insurance pricing, employment screening, and critical infrastructure. These cover risk management (Art. 9), data governance (Art. 10), documentation and transparency (Art. 11–13), human oversight (Art. 14), and accuracy/robustness (Art. 15). Non-compliance can trigger fines of up to €35 million or 7% of global annual turnover. For Chinese companies expanding overseas, the EU market is a must-address; for domestic players, the EU AI Act’s framework is also the most widely referenced standard globally—you may not be directly subject to it, but you can hardly escape its ripple effects through your suppliers, partners, and cross-border operations (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

“Domestic comparison: the EU regulates AI—what do we regulate?”

China’s governance of generative AI rests on a three-pillar approach: algorithm filing, training-data review, and security assessment, anchored by the Interim Measures for the Management of Generative AI Services, which took effect in August 2023. The biggest difference between the two regimes is not in the level of detail, but in the underlying legislative philosophy.

| Dimension | EU AI Act | China’s Generative AI Service Management Measures |
|—|—|—|—|
| Legal nature | Horizontal regulation (applies to all AI systems) | Vertical rule (focuses on generative AI services) |
| Risk tiers | 4 tiers (unacceptable / high / limited / minimal) | 2 tiers (involving public-opinion security / general commercial use) |
| Regulatory timing | Ex-ante (registration at development stage) | Ex-post (registration after launch + algorithm filing) |
| Transparency | High (requires public disclosure of training-data source summaries and model cards) | Medium (requires corpus compliance but does not mandate source disclosure) |
| Penalty cap | 7% of global revenue or €35 million | Service suspension / fines (typically multiples of illegal gains) |
| Scope | All enterprises meeting the global revenue threshold | All entities providing services within China |

In practice, AI systems at Chinese financial institutions are typically subject to three sets of rules simultaneously — the Generative AI Measures (foundation layer), the Measures for the Administration of Online Lending by Commercial Banks (business layer), plus MLPS (Multi-Level Protection Scheme, China’s cybersecurity classification regime) and algorithm filing (compliance layer). This means that for compliance-driven development in China, you cannot simply transplant the EU AI Act framework — you need to fold all three domestic tracks — “corpus compliance + algorithm filing + regulatory reporting” — into your CLAUDE.md.

For companies expanding overseas: the EU AI Act’s four-pillar framework of “risk management + data governance + documentation transparency + human oversight” is also the direction Chinese regulators are gradually aligning with — several generative AI filing feedbacks from the Cyberspace Administration of China (CAC) in 2025 already show a clear borrowing of the EU’s granularity. A compliance spec written to EU AI Act standards today will most likely remain compatible with China’s tightening regulatory trend over the next three years (CAC filing announcements 2025–2026; EU AI Act compliance deadline June 2026).

7. Implications for Decision-Makers

Takeaway one: writing a CLAUDE.md/AGENTS.md project spec is the highest-ROI engineering move in the AI era.

Its cost is 3–8 weeks of cleanup time plus 1–2 weeks of documentation. Its payoff: defect risk capped at roughly 1.7×, security vulnerabilities reduced by 2.74×, and rework down 40%+. In financial services, skipping a single compliance review rework cycle (2–4 weeks) already covers the investment. EY rolled out Copilot to 150,000 employees and saved $250 million—but only because the groundwork was already in place.

Insight #2: Spec-driven development is an organizational capability, not a tool choice.

Whether you pick GitHub Spec Kit or Claude Code doesn’t matter. What matters is whether you’ve defined how your organization collaborates with AI. Without that, even the best tool just lets your team build technical debt faster.

Insight #3: Bake specs into organizational processes, not individual memory.

If the spec lives only in a senior engineer’s head, it walks out the door the moment they leave. It has to be embedded in repo documentation, CI gates, shared team configs, and agent governance platforms. Make the spec an organizational asset, not a personal skill. Atos runs 19,000 agents across 54 countries because governance isn’t “someone knows it”—it’s “the system enforces it.”

Insight #4: Gates matter more than speed.

GitHub Spec Kit’s five-stage gating, Superpowers’ “no code before a failing test,” Kiro’s “can’t start without a spec”—all of these put a brake between AI and the final deliverable. The more capable the AI, the earlier governance needs to kick in. That 78% incident rate in New Relic’s 2026 report is the price paid by the 62% of teams shipping without review. CIOs in financial services know this better than anyone: your Change Advisory Board (Change Advisory Board (CAB)), algorithm filing requirements, and security compliance assessments (ISO 27001 certification + Cyber Essentials, China’s Multi-Level Protection Scheme) are all gates before production. AI-generated code needs the same gates—and they need to come even earlier.

Reverse self-check (no sugarcoating): How often does compliance review bounce back AI-generated code? What was the last incident caused by AI-written code? If you asked your tech lead “how do we collaborate with AI,” could they produce a document? If you can’t answer any of these three, your spec-driven practices aren’t in place yet—specs first, tools second.

Three coaching questions for decision-makers

Three questions to close with—not a checklist, but something you can use directly in conversations with your team:

  1. “If all AI tools went offline tomorrow, how much would your team’s code quality drop?” — This question exposes the real value of spec-driven development: if the answer is “significantly,” your specs haven’t been internalized yet; if the answer is “barely at all,” spec-driven is already running in production.

  2. “In your spec-driven initiative, is the compliance team a ‘gatekeeper’ or an ‘enabler’?” — If the answer is “gatekeeper,” your delivery speed will be throttled by review bottlenecks; if the answer is “enabler,” you’re already on the path outlined in Section 5.2.

  3. “Twelve to eighteen months from now, how will your team size change?” — Microsoft’s WTI 2026 answer: 82% of leaders plan to “scale” their workforce with AI agents. If your answer is “no change,” either your business isn’t growing, or your org design hasn’t caught up with the spec-driven dividend.

There are no right answers to these three questions. But the direction of your answers matters more than the answers themselves.

Next Steps

This is the sixth installment in the “Software Engineering Transformation in the AI Era” series. We started with Conway’s Law (organizations shape architecture), moved through Team Topologies (how to design the organization), then bottleneck shifting (the constraint is in verification, not coding), and today we covered spec-driven development (using documentation to constrain AI behavior).

Why “Protocols” Are the USB-C of AI: How Standardized Rules Unlock Multi-Tool, Multi-Agent Interoperability

Want to Put This Framework into Practice at Your Company?

When protocol-driven development enters an enterprise, the real issues that need solving usually come down to a few specific questions: how do core rules crystallize into CLAUDE.md / AGENTS.md, how do you retrofit existing code to comply, how do you embed compliance, and what metrics should a pilot use for acceptance.

Currently, three types of collaboration are offered:

  • Enterprise Training: Combined with your company’s real projects, this covers protocol documentation, CI gate design, compliance embedding paths, and governance mechanism construction.
  • Specialized Consulting: Focused on a specific decision, such as “Should our company write CLAUDE.md / AGENTS.md first?” or the priority of compliance remediation for existing code.
  • Management Sharing & Industry Talks: Centered around AI coding tools, protocol-driven development, organizational governance, and Frontier Firms.

The article provides a general framework, but real-world adoption still requires redesign based on your organization’s compliance requirements, regulatory boundaries, engineering maturity, and existing delivery processes. For collaboration inquiries, reach out via coach@iaiuse.com.

Further reading: The Signboard Methodology v1.0 (Learn AI Slowly 187), which lays out a 7-step framework for enterprise AI transformation.

About This Series

“Software Engineering Transformation in the AI Era” is a research series aimed at CIOs, CDOs, CTOs, and digital transformation leads across telecom, finance, manufacturing, and e-commerce. Across 18 articles, it examines how AI coding tools, specification-driven development, and organizational governance are reshaping software delivery processes, team structures, and engineering maturity.

The series continuously tracks academic papers, vendor materials, and industry reports, drawing on a research library of over 200 sources. Key claims are tagged with evidence levels, distinguishing verified facts, vendor claims, industry observations, and the author’s own reasoning.

I bring nearly 8 years of experience in large-enterprise consulting and business analysis, including a tenure at IBM working on projects in telecom, finance, insurance, and manufacturing. Since then, I’ve stayed hands-on in carrier products, internet products, and AI application development—covering requirements analysis, product design, and cross-team delivery.

This series’ judgments on standards-driven, organizational governance, and engineering practices are drawn from hands-on experience, cross-validated against public research and industry case studies. Project-specific details have been anonymized; some industry scenarios are typical problem extrapolations, with supporting references listed at the end.

Behind this account is actually a small team — myself and 1–2 long-term collaborators, each covering AI coding tool research, organizational governance case studies, and coaching conversations. Most of the projects described as “we walked enterprises through” were delivered jointly by us. Client confidentiality boundaries and individual names remain undisclosed; anonymity is preserved to leave room for future collaborators.

References (all verified, with evidence level noted per item)

  • CodeRabbit (2025.12). State of AI vs Human Code Generation Report. AI-generated code contains 1.7× more issues than human-written code (10.83 vs 6.45 issues per PR). Breakdown by category: logic/correctness 1.75×, code quality 1.64×, security 1.57×, password handling 1.88×, XSS 2.74×. Evidence tier: Level 1 Source: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263

  • The Register (2025.12.17). Coverage of the full CodeRabbit report: analysis of 470 open-source PRs shows AI-assisted PRs averaging 10.83 issues versus 6.45 for purely human-authored ones. Evidence tier: Level 2 Source: same URL as above.

  • CodeRabbit / David Loker (Jan 2026). “2026 Predictions: The Speed Trap” — 2026 marks the shift from “code generation speed” to “code quality and governance.” Evidence level: Tier 2. Source: https://tfir.io/ai-code-quality-2026-guardrails

  • New Relic (2026). The 2026 State of AI Coding Report. 78% of teams report more incidents after shipping AI-generated code; 62% of technical leaders admit their teams “confidently ship AI code without review”; 96% say observability is a must-have. Evidence level: Tier 1 (vendor report). Source: https://newrelic.com/resources/report/2026-state-of-ai-coding

  • Microsoft 2026 Work Trend Index Annual Report (May 5, 2026). Survey of 20,000 AI workers across 10 countries; 82% of leaders plan to expand their workforce with AI agents within 12–18 months; 81% expect moderate to significant agent integration; 24% have already deployed at enterprise scale; 49% of Copilot conversations support knowledge work; 58% of AI users report doing things “they couldn’t do a year ago,” rising to 80% among Frontier Professionals. Evidence tier: Level 1. Source: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf

  • Microsoft FY26 Retrospective: From AI Experimentation to Frontier Transformation (2026.7.28). EY deployed Microsoft 365 Copilot to 150,000 employees, saving 2.5 million hours and approximately $250 million; the rollout has since expanded to 400,000 global employees, with 95% faster task completion, a 37% reduction in finance operations costs, and up to 90% reduction in manual workflows. Atos rolled out Copilot to 56,000 employees across 56 countries, alongside 19,000 AI agents, unified under a single identity, security, compliance, and governance control plane. Evidence tier: Level 1 (official Microsoft retrospective). Source: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Atos Group and Microsoft Strategic Collaboration (2026.6.9). Atos is deploying Microsoft 365 E7 (Frontier Suite) across 56 countries for 56,000 employees, plus 19,000 AI agents, with a unified control plane spanning Entra, Defender, Intune, Purview, and Agent 365. Evidence level: Tier 1 (joint press release). Source: 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 (open-sourced Sep 2025, evolving through H1 2026). Five-stage gated workflow /speckit.constitution → /specify → /plan → /tasks → /implement, plus /clarify /analyze; model-agnostic (works with Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code). Evidence level: Tier 1. Source: https://github.com/github/spec-kit

  • AWS Kiro (released Jul 2025, evolving through H1 2026). Three-stage workflow: requirements → design → tasks; specs trigger predefined agent actions; the workflow won’t start without a spec. Evidence level: Tier 1. Source: https://kiro.dev/

  • OpenAI Codex + AGENTS.md + Skills (2025-2026). Codex hit 5M+ weekly active users by June 2026, with 20% non-developers; AGENTS.md + Skills form a composable instruction set. Evidence level: Tier 1 (official OpenAI announcement). Source: https://developers.openai.com/codex/skills

  • Claude Code (Anthropic, H1 2026). CLAUDE.md + .claude/rules/ + Skills system; entered Anthropic’s official marketplace in February 2026; Skills repository has 112K stars on GitHub; Series G disclosure in February 2026 showed $2.5B annualized revenue. Evidence level: Tier 1. Source: https://code.claude.com/docs/en/claude-directory

  • JetBrains AI Tools Research (2026.2). 15,000 developers surveyed; 46% chose Claude Code as “most loved,” Cursor 19%, Copilot 9%. Evidence level: Tier 1. Source: https://www.jetbrains.com/lp/tools/ai-tools/

  • Pragmatic Engineer Newsletter (2026.2). 15,000 developer survey; 46% picked Claude Code as “most loved,” Cursor 19%, Copilot 9%. Evidence level: Tier 1. Source: https://newsletter.pragmaticengineer.com/

  • Alibaba Qoder (Aug 2025 → Jul 2026). Released by Alibaba in Aug 2025; on May 15, 2026, Qoder 1.0 was upgraded to an Autonomous Agent Development Workbench, featuring Spec-Driven Workflow, Quest Mode, Expert Mode, and RepoWiki; on May 28, 2026, Cloud Agents (a managed agent runtime) was introduced; on Jul 21, 2026, Qoder Security followed. By May 2026, Qoder had surpassed 5 million global users. It also integrates with Microsoft Teams CLI. On May 20, 2026, Tongyi Lima was renamed Qoder CN. Evidence level: primary. Sources: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525

  • vibecoding.app / thebcms.com / tfir.io (2026 H1). Spec Kit five-phase commands, SDD tool evaluations and comparisons, EARS notation method. Evidence level: Tier 2 (third-party evaluations). Sources: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development

  • EU AI Act / Code of Practice (full enforcement from Aug 2, 2026). Compliance deadline for high-risk AI systems is Aug 2, 2026; existing GPAI models are extended to Aug 2, 2027; fines up to €35 million or 7% of global annual revenue; Articles 9–15 cover risk management, data governance, documentation transparency, human oversight, and accuracy/robustness. Evidence level: Tier 1 (regulation + secondary compliance analysis). Sources: 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). 44% of issues stem from missing context. Evidence level: Tier 2 (vendor report). Source: https://www.qodo.ai/reports/state-of-ai-code-quality/

]]> AI code defects 1.7x, security vulns 2.74x—AI cannot see your rules. Spec Kit, Kiro, Codex, Claude Code, Qoder move to spec-driven in 2026 H1: CLAUDE.md. 【Spec-Driven】Spec-Driven Development：Escribir especificaciones es la acción de ingeniería con mayor ROI en la era de la IA — La transformación de la ingeniería de software en la era de la IA — Learn AI Slowly 177 https://iaiuse.com/es/posts/spec-driven-development-escribir-especificaciones-es-la-accion-de-ingenieria-de-mayor-roi-en-la-era-de-ia 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z

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

EmpresaAvances (2026 H1)Lecciones Aprendidas (2026 H1)
EYImplementació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 globalesReconoce que el 95% de aumento de velocidad y el 37% de reducción de costos financieros se deben a la “normalización previa”
AtosDespliegue en 54 países / 56,000 empleados; ejecución simultánea de 19,000 agentes de IA, control unificado de identidad, seguridad, cumplimiento y gobernanzaInsiste 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 mesesReconoce 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.

Código de IA vs código humano: distribución de defectos (análisis de 470 PR de código abierto) Informe CodeRabbit 2025.12｜todos los números son múltiplos de IA / humano (línea base 1.0)

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”.

Rutas impulsadas por estándares de las cinco plataformas (2025-2026 H1) GitHub Spec Kit Código abierto 2025.9 constitution.md Compuerta de cinco fases: constitution → specify → plan → tasks → implement Independiente del modelo, admite 8+ agentes Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md Flujo de trabajo en tres fases: Requisito → Diseño → Tarea Spec-driven integrado en el IDE Agente automático por disparador Cumplimiento/auditoría preinstalados Sin spec no se inicia OpenAI Codex 2025-2026 AGENTS.md + Sistema de Skills Conjunto de instrucciones combinable Configuración compartida por equipo 5M+ semanales (2026.6) 20% no desarrolladores De programación a agente general Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + Habilidades (mercado oficial 2026.2) + Ecosistema MCP CSAT 91% / NPS 54 $2.5B ARR（2026.2） 112 mil estrellas en GitHub Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Modo Quest de ejecución autónoma + Modo Experto en equipo + Contexto RepoWiki Más de 5M de usuarios globales (2026.5) 2026.7.21 Qoder Security CLI de Microsoft Teams ya integrado Paradigma común: escribir explícitamente "cómo colaboramos con IA" como documento en el repositorio Que todas las personas y todos los agentes de IA trabajen con la misma especificación: esa es la esencia del enfoque basado en normas 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 (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%).

Tres fases de implementación normativa en finanzas (versión práctica H1 2026) Fase 1: Inventariar reglas 2-4 semanas｜Lo más costoso, mayor ROI Lista de requisitos de cumplimiento (seguridad/exportación/registro) Reglas de seguridad (contraseñas/cifrado/logs) Reglas de negocio (control de riesgos/transacciones/facturación) Restricciones técnicas (interfaces antiguas/límites de versión) Gobernanza de proveedores (contratos/auditorías/responsabilidad) Reunir las reglas dispersas Organizarlas en documentación estructurada Segunda fase: integrar en el repositorio 1-2 semanas｜en el repo, IA carga automáticamente CLAUDE.md / AGENTS.md constitution.md Definición de Skills (flujo de trabajo compartible) Diseño de proceso de control (cinco fases) .claude/rules/ (reglas por capas) Poner las reglas en el repo, IA carga automáticamente Tercera fase: institucionalización Continuo｜de herramienta a capacidad organizativa Control CI (revisión automática) Configuración compartida del equipo (Skills) Mecanismo de actualización periódica (revisión trimestral) Métricas (tasa de defectos / tasa de cumplimiento) Gobernanza de agentes (Agente 365 nivel 1) Las normas se convierten en activos organizacionales, Sin depender de individuos

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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
# 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 Change Advisory Board (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”:

  1. 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.

  2. 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”.

  3. 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 (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ónEU AI ActMedidas de Gestión de Servicios de IA Generativa de China
Naturaleza jurídicaRegulación horizontal (aplica a todos los sistemas de IA)Regulación vertical (centrada en servicios de IA generativa)
Clasificación de riesgo4 niveles (inaceptable / alto / limitado / mínimo)2 niveles (relacionados con la seguridad de la opinión pública / uso comercial general)
Momento de supervisiónEx ante (registro desde el desarrollo)Ex post (registro tras el lanzamiento + registro del algoritmo)
TransparenciaAlta (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 sanciones7 % de los ingresos globales o 35 millones de eurosSuspensión del servicio / multas (generalmente múltiplos de las ganancias ilícitas)
Ámbito de aplicaciónTodas las empresas que superen el umbral de ingresos globalesTodas 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:

  1. “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.
  2. “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.
  3. “¿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/

]]> Defectos IA 1,7×, vulnerabilidades 2,74×: la IA no ve tus reglas. En 2026 H1 cinco plataformas convergen hacia reglas en CLAUDE.md dentro del repositorio. 【Spécifications d'abord】Spec-Driven Development — rédiger les spécifications, l'action d'ingénierie au ROI le plus élevé à l'ère de l'IA — Apprendre l'IA lentement n°177 https://iaiuse.com/fr/posts/spec-driven-development-redaction-des-specifications-roi-eleve-ere-ia 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z

Sources des données : CodeRabbit 2025.12 / Rapport New Relic 2026, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. Les cas présentés sont des scénarios représentatifs ; ils ne renvoient à aucune entreprise identifiée.

Votre plus grande erreur n’est pas de ne pas avoir acheté d’outils, mais de ne pas avoir écrit CLAUDE.md

Un DSI d’une grande banque française me confiait récemment : « Nous avons acheté les outils d’IA, déployé les modèles, formé les équipes — et pourtant, depuis le début 2026, nos cycles de livraison n’ont quasiment pas bougé. » Le responsable de l’équipe systèmes centraux était encore plus direct : « Le code produit par l’IA est utilisable, mais il faut le réécrire à chaque fois — il ne connaît pas nos règles internes, il ne comprend pas les exigences réglementaires, et il ne sait pas dialoguer avec notre système historique vieux de 30 ans. »

Le problème ne tient pas à une IA trop faible. Il tient à ce que vous n’avez pas écrit vos règles. L’analyse de CodeRabbit, menée en décembre 2025 sur 470 pull requests open source, a livré un jeu de chiffres largement repris depuis : les PR assistées par IA contiennent en moyenne 10,83 problèmes, contre 6,45 pour les PR purement humaines — 1,7 fois plus, soit 70 % de bugs supplémentaires. En 2026, la tendance ne s’est pas inversée : dans son 2026 State of AI Coding Report, New Relic constate que 78 % des équipes déclarent davantage d’incidents après la mise en production de code généré par l’IA, et que 62 % des responsables techniques admettent que leurs équipes « publient en confiance, sans relire ligne par ligne » ce code d’IA (rapport officiel New Relic 2026, score 0,866, source primaire). Ces deux jeux de données disent la même chose : l’IA n’est pas dépourvue de capacités, elle manque de contexte.

À l’aube du mois d’août 2026, tout récit d’accélération de la transformation par l’IA doit être confronté à une mise en regard :

ActeurAvancées (S1 2026)Contre-exemples (S1 2026)
EYMicrosoft 365 Copilot déployé auprès de 150 000 collaborateurs, soit 2,5 millions d’heures / 250 millions de dollars économisés ; extension prévue à 400 000 collaborateurs dans le mondeReconnaît dans le même temps que les gains de 95 % de productivité et la baisse de 37 % des coûts de la fonction finance reposent sur la condition préalable « spécifications d’abord »
AtosDéploiement dans 54 pays / 56 000 collaborateurs ; 19 000 agents IA exécutés en parallèle, sur un plan de contrôle unifié pour l’identité, la sécurité, la conformité et la gouvernanceTenue stricte du principe « gouvernance d’Agent 365 opérationnelle avant toute montée en charge »
Microsoft en interneWork Trend Index 2026 : 82 % des dirigeants prévoient d’étendre leur main-d’œuvre avec des agents IA sous 12 à 18 moisReconnaît dans le même temps que « le rythme du changement organisationnel est en retard sur l’adoption individuelle » — la contradiction fondatrice du concept de Frontier Firm

Sources : rétrospective Microsoft FY26 du 28 juillet 2026 ; Microsoft 2026 Work Trend Index Annual Report du 5 mai 2026 ; New Relic 2026 State of AI Coding Report.

Cette mise en regard fait apparaître un invariant : sans spécifications, la mise à l’échelle multiplie les risques par N. La « rapidité » d’EY, d’Atos et de Microsoft ne tient pas à la vitesse du modèle, mais au fait que leurs organisations ont d’abord répondu à la question : « comment utilisons-nous l’IA ? » C’est dans ce contexte que le Spec-Driven Development (SDD, pilotage par spécifications) s’est réellement imposé au premier semestre 2026 — non par préférence des ingénieurs pour la documentation, mais parce qu’il est désormais impossible de survivre dans un environnement peuplé de 19 000 agents sans avoir écrit ses règles.

Cet article clarifie trois points : 1) pourquoi le code généré par IA présente un taux de défauts au moins 1,7 fois supérieur au code humain ; 2) comment GitHub, AWS, OpenAI, Anthropic et Alibaba ont convergé vers un même paradigme au premier semestre 2026 — contraindre le comportement de l’IA par la documentation ; 3) pourquoi le pilotage par spécifications est une capacité organisationnelle, et non un choix d’outil, ainsi que les trois étapes concrètes de déploiement au S1 2026.

Code IA vs code humain : répartition des défauts (analyse de 470 PR open source) Rapport CodeRabbit 2025.12 ｜ tous les chiffres sont des ratios IA / humain (ligne de base 1.0)

Longueur des barres = multiple des défauts IA par rapport à l’humain ; ligne de base 1.0× = niveau humain

Référence 1.0×

Nombre total de problèmes

1.7×
IA 10,83 vs humain 6,45 / PR

Erreurs de logique / exactitude

1.75×

Qualité du code / maintenabilité

1.64×

Constats de sécurité (global)

1.57×

Mauvaise gestion des mots de passe

1.88×

Vulnérabilités XSS

2.74×
↑ Maximum

Code IA sans contraintes normatives : supérieur à l’humain sur toutes les dimensions
Finance / télécoms = rapprochement réglementaire, gestion des mots de passe, chiffrement des champs sensibles — l’IA ne voit rien

I. Le taux de défauts de l’IA n’est pas un problème de modèle, mais un problème de contexte

Une phrase du rapport CodeRabbit est régulièrement citée : « L’IA manque de logique métier locale : le modèle déduit les patterns de code par inférence statistique, et non par compréhension sémantique. En l’absence de contraintes strictes, il laisse passer les règles que les ingénieurs chevronnés ont intériorisées. »

Cette phrase explique pourquoi la propre plateforme de programmation IA de CodeRabbit — entreprise spécialisée dans la revue de code par IA — a vu ces chiffres plus tôt que d’autres : ils examinent chaque jour des milliers de pull requests, et voient chaque jour à quoi ressemble le code écrit par l’IA. La découverte « la plus saillante » n’est pas le total, c’est la répartition :

  • Logique / exactitude +75 % : erreurs de logique métier, erreurs de dépendances, erreurs de flux de contrôle, erreurs de configuration — ces problèmes ne sont pas forcément détectés par les tests, mais provoquent des incidents en production.
  • Qualité du code +64 % : incohérences de nommage, structure peu claire, non-respect des patterns du projet — c’est la « catégorie d’écart la plus marquée ». Un ingénieur expérimenté repère immédiatement : « ce n’est pas écrit comme ici ».
  • Sécurité +57 % (XSS en tête avec 2,74×) : mauvaise gestion des mots de passe (1,88×), références d’objets non sécurisées (1,91×), fuite d’informations sensibles, désérialisation non sécurisée (1,82×) — dans la banque, ce n’est pas « est-ce que ça marche », c’est « est-ce qu’on peut le mettre en production ».

Le problème ne tient pas à une IA insuffisamment puissante. Il tient au fait qu’elle ne voit rien.

Pour revenir au blocage réel de ce DSI, voici trois défaillances concrètes de l’IA dans un système financier critique :

Premièrement, l’IA ne voit pas 30 ans de logique de rapprochement. Les règles de gestion des risques d’une banque sont inscrites dans les procédures stockées du système central — écrites il y a 30 ans, dont plus personne ne se souvient intégralement. Le code produit par l’IA semble correct, mais en production, il déclenche ce contrôle de rapprochement oublié de tous, et fait échouer tout un lot de transactions.

Deuxièmement, l’IA ne voit pas les contraintes réglementaires. Les mots de passe doivent passer par un système de gestion des clés (KMS), les champs sensibles doivent être chiffrés au stockage, les logs ne doivent pas afficher d’informations clients — ce sont des contraintes réglementaires strictes, consignées dans les politiques internes. L’IA les ignore : le code qu’elle produit fonctionne, mais ne passe pas la conformité.

Troisièmement, l’IA ne voit pas votre dette technique. Le système hôte vieux de 30 ans utilise son propre protocole d’interface, dont la documentation a disparu depuis longtemps. L’IA écrit du code conforme aux normes REST génériques ; une fois en production, on s’aperçoit que les interfaces ne correspondent pas — deux semaines de reprise.

Pour en revenir aux chiffres de New Relic : 62 % des équipes « publient en confiance, sans revue » du code généré par IA, et 78 % signalent davantage d’incidents après mise en production. Mis bout à bout, ces deux chiffres disent une seule chose — le taux de défauts du code IA n’est pas en soi le problème ; « je ne sais pas quels défauts contient le code IA » est le vrai problème.

Scénario typique : une grande banque française introduit l’assistance par IA pour développer le module de contrôle des risques de son système central. En trois mois, le taux de rejet lors des revues de conformité bondit — les principaux motifs portent sur la gestion des mots de passe, le chiffrement des champs sensibles, la conformité des journaux et autres règles internes. Toutes ces règles sont consignées dans des documents internes, mais l’IA n’y a pas accès. L’équipe consigne ensuite les règles clés dans un fichier CLAUDE.md, et le taux de rejet chute nettement.

II. Les cinq grandes plateformes au S1 2026 — une convergence vers le « pilotage par spécifications »

GitHub a publié Spec Kit en juillet 2025 ; début 2026, AWS Kiro, OpenAI Codex et Anthropic Claude Code ont complété leur offre ; en mai 2026, Alibaba Qoder a intégré le « Spec-Driven Workflow » dans son positionnement produit. Les cinq grandes plateformes ont convergé au S1 2026 vers un même paradigme — utiliser la documentation pour contraindre le comportement de l’IA. Ce n’est pas l’invention d’un seul acteur, c’est la réponse collective du secteur à la « crise de qualité du code généré par l’IA ».

Parcours pilotés par les spécifications des cinq grandes plateformes (2025-2026 S1) GitHub Spec Kit Open source 2025.9 constitution.md Porte à cinq étapes : constitution → specify → plan → tasks → implement Indépendant du modèle, compatible 8+ agents Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md Workflow en trois étapes : Besoin → Conception → Tâches Pilotage par spec intégré au flux IDE Hooks : déclenchent automatiquement les agents Hooks conformité / audit préinstallés Impossible de démarrer sans spec OpenAI Codex 2025-2026 AGENTS.md + Système de Skills Jeu d'instructions composable Configuration partagée d'équipe 5M+ actifs hebdo (2026.6) 20 % non-développeurs De la programmation à l'agent généraliste Claude Code Anthropic S1 2026 CLAUDE.md + .claude/rules/ + Skills (Marché officiel 2026.2) + Écosystème MCP CSAT 91 % / NPS 54 2,5 Md$ ARR (2026.2) 112 000 étoiles GitHub Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Mode Quête autonome + Mode Expert en équipe + Contexte RepoWiki 5M+ utilisateurs mondiaux (2026.5) 2026.7.21 Qoder Security CLI Microsoft Teams intégrée Paradigme commun : formaliser par écrit « comment nous collaborons avec l'IA » dans un document placé dans le dépôt Faire travailler tous les humains et tous les agents IA à partir de la même référence — voilà l'essence du pilotage par spécifications

Passons en revue les dernières avancées de chaque plateforme au premier semestre 2026 :

GitHub Spec Kit : implémentation de référence, processus à cinq étapes avec portes de validation. Open-sourcé en septembre 2025, il s’est imposé comme l’implémentation de référence du secteur au S1 2026. 5 commandes principales + 2 complémentaires : /speckit.constitution (principes non négociables), /speckit.specify (quoi et pourquoi), /speckit.plan (comment modifier), /speckit.tasks (décomposition des tâches), /speckit.implement (exécution), auxquelles s’ajoutent /clarify et /analyze. Sa conception clé repose sur le principe d’indépendance vis-à-vis du modèle : les mêmes fichiers spec/plan/tasks ne sont liés à aucun agent d’exécution précis et peuvent être repris par Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf ou Qwen Code. C’est ce qui en fait un « protocole SDD au niveau organisationnel », et non un produit exclusif à GitHub (évaluation vibecoding.app, juin 2026, score 0,816, source secondaire).

AWS Kiro : le pilotage par spécifications inscrit dans l’IDE. Lancé en juillet 2025, AWS Kiro a évolué au S1 2026 pour devenir un IDE agentique complet. Son flux de travail se déploie en trois phases : exigences → conception → tâches. Ce qui le distingue de Spec Kit, ce sont ses « hooks » — les fichiers de spécification de Kiro peuvent déclencher des actions d’agent prédéfinies et intégrer au flux de travail des étapes qui font intervenir des systèmes externes, comme la conformité, l’audit ou le déploiement. Si vous voulez imposer la rédaction de spécifications à votre équipe, choisissez Kiro — sans spec, Kiro ne démarre tout simplement pas (AWS Kiro, juillet 2025 ; documentation Kiro.dev, 2026).

OpenAI Codex : AGENTS.md + Skills composables. Entre 2025 et 2026, OpenAI a propulsé AGENTS.md au centre de son écosystème. Les Skills constituent l’extension clé du S1 2026 : elles permettent de pré-assembler des séquences de travail — « lire un fichier Excel », « générer du SQL », « exécuter une migration de données » — et de les invoquer à la manière de briques Lego. En juin 2026, Codex dépassait les 5 millions d’utilisateurs actifs hebdomadaires, dont 20 % de non-développeurs — un signal souvent négligé : le pilotage par spécifications ne concerne plus seulement les équipes d’ingénierie, mais l’ensemble de l’entreprise. Les équipes produit, opérations et gestion des risques rédigent désormais leurs propres fichiers AGENTS.md (annonce OpenAI du 2 juin 2026 ; évaluation thebcms.com, 2026, score de 0,801).

Claude Code : CLAUDE.md + .claude/rules/ + Skills. Anthropic désigne son fichier de directives projet sous le nom de CLAUDE.md (entré sur le marché officiel en février 2026), .claude/rules/ (règles hiérarchisées par répertoire) et Skills (flux de travail partageables). Claude Code est l’outil affichant le plus haut taux de satisfaction développeur au S1 2026 — l’enquête JetBrains 2026.1 lui attribue un CSAT de 91 % et un NPS de 54, chiffres confirmés par deux études indépendantes (Pragmatic Engineer, février 2026). C’est la meilleure note du secteur dans la catégorie des assistants de codage IA (uvik.net, mai 2026, score 0,956, agrégation de sources primaires). Claude Code est passé de zéro à 2,5 milliards de dollars de revenus annualisés en neuf mois (chiffres du tour G d’Anthropic, février 2026), avec 112 000 étoiles sur GitHub (dépôt Skills) — les développeurs votent avec leurs pieds, et ce vote témoigne de la valeur réelle d’une approche pilotée par les règles.

Alibaba Qoder : le pilotage par spécifications sur le marché chinois. Lancé en août 2025, Qoder est passé en version 1.0 le 15 mai 2026, se repositionnant officiellement d’« IDE IA » à « poste de travail pour le développement d’agents autonomes » (Autonomous Agent Development Workbench). Son Spec-Driven Workflow a été introduit en même temps que le Quest Mode (tâches multi-fichiers autonomes), l’Expert Mode (exécution parallèle par équipes d’experts) et RepoWiki (graphe de connaissances du dépôt). Le 28 mai 2026 sont arrivés les Cloud Agents (runtime d’agents entièrement géré), suivis le 21 juillet de Qoder Security (capacités de conformité et de sécurité), puis d’une version Mobile (Android/iOS/HarmonyOS) le même mois. En mai 2026, Qoder comptait déjà plus de 5 millions d’utilisateurs dans le monde, et la CLI Microsoft Teams le répertorie parmi les environnements d’exécution d’agents pris en charge (Yahoo Finance 2025 ; Alibaba Cloud officiel 2026 ; Baidu Baike, juillet 2026).

Paradigme commun : formaliser explicitement « comment nous collaborons avec l’IA » dans un document, le placer dans le dépôt, et faire en sorte que tous les humains et tous les agents IA travaillent à partir de cette même référence. Les cinq plateformes diffèrent dans les détails d’implémentation (nom des fichiers, nombre de phases, mécanismes de hooks), mais l’objectif est strictement identique.

Pourquoi cette convergence au S1 2026 ? Parce que le seuil de capacité de l’IA est déjà franchi — avec les agents autonomes de Claude Code, le multi-agents parallèle de Codex, la refactorisation multi-fichiers de Cursor, l’IA n’est plus un « outil de complétion », c’est un « collègue ». Le document d’onboarding que vous remettriez à un nouveau collaborateur doit pouvoir être lu par l’IA aussi.

III. Le pilotage par spécifications est une capacité organisationnelle, pas un choix d’outil

C’est le point le plus important pour les décideurs. Le pilotage par spécifications ne consiste pas à choisir un outil, mais à définir « comment notre organisation collabore avec l’IA ». Que vous optiez pour GitHub Spec Kit ou Claude Code importe peu. Ce qui compte, c’est de savoir si vous avez formalisé vos spécifications dans un document, placé ce document dans le dépôt, et fait en sorte que tous les humains et toutes les IA travaillent à partir de cette même référence.

Sans cela, les meilleurs outils ne font qu’accélérer la production de dette technique par votre équipe.

Observé à l’aune du déploiement à grande échelle au S1 2026, le constat est encore plus net. Dans sa rétrospective FY26 de juillet 2026, Microsoft a érigé les cas d’EY et d’Atos en modèles de « Frontier Firm » — non pas parce que les modèles étaient nouveaux, mais parce que ces deux organisations ont d’abord répondu à la question : « comment utilisons-nous l’IA ? »

EY : la gouvernance先行, la mise à l’échelle ensuite. Entre 2024 et 2025, EY a déployé Microsoft 365 Copilot auprès de 150 000 collaborateurs, économisant 2,5 millions d’heures et environ 250 millions de dollars. La condition préalable : un cadre de gouvernance de l’IA établi en amont. EY a construit une chaîne d’outils unifiée avec Power Platform, Copilot Studio, Azure, Foundry et Fabric, intégrant conformité, réglementation et audit dans un même socle. C’est ce socle qui a permis ensuite les gains de 95 % de productivité, la baisse de 37 % des coûts de la fonction finance et la réduction pouvant atteindre 90 % des flux de travail manuels. La vice-présidente d’EY l’a dit sans détour lors de l’AI Tour 2026 : « Nous n’avons pas d’abord déployé l’IA pour ajouter la gouvernance ensuite ; nous avons d’abord mis la gouvernance en place, puis déployé l’IA. »

Atos : un plan de contrôle unifié pour 19 000 agents. Atos fait partie des toutes premières organisations au monde à avoir déployé Microsoft 365 E7 (Frontier Suite), étendant Copilot à 56 000 collaborateurs répartis dans 54 pays. L’entreprise fait simultanément tourner 19 000 agents IA — qu’il s’agisse de l’IT interne, des directions métiers ou de projets clients, tout est construit via Foundry et Copilot Studio. La clé de la réussite d’Atos tient à un seul principe : « un plan de contrôle unique ». Cinq briques y sont étroitement liées : Entra (identité), Defender (sécurité), Intune (appareils), Purview (conformité) et Agent 365 (gouvernance des agents). Cette approche intégrée trouve son équivalent dans le secteur financier sous la forme d’une architecture de gouvernance — couvrant la conformité réglementaire (équivalent français de la classification de sécurité NIS2 / ISO 27001), les transferts de données transfrontaliers (équivalent RGPD), l’enregistrement des algorithmes (EU AI Act), l’audit et la gouvernance des modèles — bien plus qu’un simple outil d’IA.

Le paradoxe du changement organisationnel chez Microsoft. Dans son rapport Work Trend Index 2026, Microsoft reconnaît explicitement un décalage : « le rythme du changement organisationnel est en retard sur l’adoption individuelle ». Parmi les 20 000 utilisateurs d’IA interrogés, 82 % des dirigeants prévoient d’étendre leur main-d’œuvre avec des agents IA sous 12 à 18 mois, mais seuls 24 % ont déjà déployé ces solutions à l’échelle de l’entreprise. 81 % des dirigeants s’attendent à ce que les agents IA soient intégrés de manière modérée ou significative dans leur stratégie IA — mais là encore, seuls 24 % l’ont fait. Autrement dit, la majorité des entreprises se trouvent à 12-18 mois d’écart entre « l’intention » et « la réalisation ». Pour combler ce fossé, la gouvernance par les spécifications constitue le principal levier.

Sources : rétrospective Microsoft FY26 du 28 juillet 2026 ; Microsoft 2026 Work Trend Index Annual Report du 5 mai 2026 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, source primaire PDF) ; analyse Futurum Group du 26 janvier 2026 (source secondaire).

Enseignement n°1 : investir dans la gouvernance, un ROI élevé.

Les données CodeRabbit fournissent une base de calcul claire : le taux de problèmes liés à l’IA est environ 1,7 fois supérieur à celui du code humain, et les vulnérabilités de sécurité sont réduites d’un facteur 2,74×. Concrètement :

  • Moins de reprises (dans la banque, une reprise liée à un contrôle de conformité peut coûter 2 à 4 semaines)
  • Moins d’incidents de sécurité (une fuite de données entraîne amendes réglementaires et perte de réputation)
  • Des coûts de maintenance réduits (une diminution de 40 % de la dette technique est un chiffre courant)

Rédiger une spécification projet CLAUDE.md/AGENTS.md est l’action d’ingénierie au ROI le plus élevé à l’ère de l’IA. Le cas EY offre une traduction concrète : 150 000 collaborateurs équipés de Copilot, pour 250 millions de dollars d’économies. À noter : EY n’a pas économisé parce que l’outil est « puissant », mais parce que la spécification a permis d’en concrétiser la valeur.

Enseignement n°2 : inscrire les spécifications dans les processus de l’organisation, plutôt que de dépendre des individus.

Si une spécification n’existe que dans la tête d’un ingénieur senior, elle se perd dès qu’il change d’équipe ou d’entreprise. Elle doit être formalisée dans :

  • La documentation du dépôt (AGENTS.md / CLAUDE.md / constitution.md)
  • Les portes de validation CI (vérification automatique du respect des spécifications)
  • La configuration partagée d’équipe (le système Skills permet à toute l’équipe de l’utiliser)

Faire de la norme un actif d’organisation, pas une compétence individuelle. C’est particulièrement crucial dans la banque — vos exigences de conformité, vos règles de sécurité et vos règles métier sont des actifs au niveau de l’organisation, et non « l’expérience » d’un ingénieur. Les 19 000 agents d’Atos fonctionnent dans 54 pays parce que la gouvernance n’est pas « l’affaire de spécialistes », mais une « contrainte systémique ».

Enseignement n°3 : le contrôle d’accès prime sur la vitesse.

Les cinq étapes de validation de GitHub Spec Kit (constitution → specify → plan → tasks → implement), la règle de Claude Code « pas de code avant l’échec des tests », et l’impossibilité de démarrer sans spec chez Kiro — toutes ces approches font la même chose : introduire un « frein » entre l’IA et le livrable final. Chaque étape produit un artefact vérifiable (spec.md, plan.md, tasks.md), qui peut être rejeté ou modifié avant la génération du code.

Plus l’IA est autonome, plus le contrôle est nécessaire. Le comité de changement (Change Advisory Board, Change Advisory Board (CAB)) dans la finance, les procédures d’enregistrement des algorithmes et les évaluations de sécurité (équivalentes d’ISO 27001 / SOC 2) sont essentiellement des contrôles ajoutés avant la mise en production. Le code généré par l’IA appelle les mêmes types de contrôle, sous une forme différente. Les 62 % d’équipes qui « publient en confiance, sans revue » selon le rapport New Relic 2026 paient cette confiance par un taux d’incidents plus élevé (78 %).

Déploiement sectoriel finance en trois phases (version pratique S1 2026) Phase 1 : inventaire des règles 2-4 semaines | le plus chronophage, ROI maximal Liste des exigences de conformité (NIS2 / RGPD / EU AI Act) Règles de sécurité (mots de passe / chiffrement / journaux) Règles métier (contrôle des risques / transactions / facturation) Contraintes techniques (anciennes interfaces / versions) Gouvernance fournisseurs (contrats / audits / responsabilités) Regrouper les règles dispersées Les structurer en documentation organisée Phase 2 : intégration au dépôt 1-2 semaines | dans le dépôt, chargement automatique par l'IA CLAUDE.md / AGENTS.md constitution.md Définition des Skills (workflows partageables) Conception du processus de contrôle (cinq phases) .claude/rules/ (règles hiérarchisées par répertoire) Placer les règles dans le dépôt, chargement automatique par l'IA Phase 3 : institutionnalisation Continu | de l'outil à la capacité organisationnelle Portes CI (revue automatique) Configuration partagée d'équipe (Skills) Mécanisme de mise à jour régulière (revue trimestrielle) Métriques (taux de défauts / taux de conformité) Gouvernance des agents (Agent 365 niveau 1) Les normes deviennent des actifs organisationnels, sans dépendance individuelle

La première phase est la plus longue, mais c’est celle au ROI le plus élevé
Dans la plupart des institutions financières, les règles sont dispersées entre documents, e-mails et mémoire collective : la première consolidation prend 3 à 8 semaines

IV. Les trois phases concrètes de déploiement au premier semestre 2026

Prenons l’exemple du secteur bancaire français pour illustrer ce parcours en trois phases, transposable aux autres secteurs fortement réglementés. Les pratiques d’EY et d’Atos au S1 2026 correspondent précisément à ces trois étapes.

Phase 1 : inventaire des règles (2 à 4 semaines).

C’est l’étape la plus chronophage, mais aussi celle au retour sur investissement le plus élevé. Il s’agit de recenser toutes les règles dispersées dans l’organisation :

  • Exigences de conformité : dans la banque, le socle minimal = classification de sécurité NIS2 / ISO 27001 + évaluation des transferts de données transfrontaliers (mécanisme RGPD) + enregistrement des algorithmes sous l’EU AI Act (il ne faut pas déployer d’IA s’il manque un seul de ces éléments). S’ajoutent ensuite les obligations de reporting réglementaire (ACPR, BCE), la protection des données clients, les restrictions sur les flux transfrontaliers, et la définition de ce qui peut être exposé à l’IA
  • Règles de sécurité : gestion des mots de passe, normes de chiffrement, traitement des champs sensibles, exigences de journalisation
  • Règles métier : seuils de risque, conditions d’indemnisation, limites de transaction, logique de facturation
  • Contraintes techniques : interfaces des systèmes existants, conventions de nommage des bases de données, versions de frameworks
  • Gouvernance des fournisseurs : comment imposer nos normes aux fournisseurs dans les contrats, comment auditer leur usage de l’IA

Scénario typique : lors de la phase d’inventaire, une société de valeurs mobilières constate que ses règles sont éparpillées dans une multitude de documents Word, de wikis JIRA, d’e-mails personnels et de feuilles Excel — ce n’est qu’après consolidation qu’elle obtient une liste structurée de règles. L’approche d’Atos est plus systématique : elle répartit directement les règles en cinq catégories — conformité, sécurité, métier, technique, fournisseurs — chacune dotée d’un workflow de gouvernance dédié, le tout branché sur le plan de contrôle d’Agent 365.

Ce n’est pas un exercice technique, c’est un exercice d’organisation : il faut réunir les équipes conformité, sécurité et métier autour d’une même table, et formaliser les règles que tout le monde accepte. La première fois, une organisation financière y consacre généralement 3 à 8 semaines — mais c’est un actif organisationnel permanent.

Phase 2 : intégration au dépôt (1 à 2 semaines).

Les règles consolidées en phase 1 sont rédigées sous forme de documents et placées dans le dépôt. GitHub Spec Kit utilise constitution.md, Claude Code s’appuie sur CLAUDE.md, OpenAI Codex sur AGENTS.md, et Alibaba Qoder sur Spec Workflow. Les noms de fichiers diffèrent, mais l’objectif est identique — faire en sorte que l’IA charge ces règles dès l’ouverture du dépôt.

Structure suggérée (format dominant au premier semestre 2026) :

  • Vue d’ensemble du projet : ce que fait le système, à qui il s’adresse
  • Principes non négociables : lignes rouges sécurité, conformité, métier
  • Stack technique et contraintes : framework, base de données, normes d’interface
  • Normes de code : conventions de nommage, arborescence, seuil minimal de couverture des tests (sans imposer le rythme TDD — préciser le taux de couverture, les chemins obligatoires et les chemins interdits ; le TDD reste un choix organisationnel, pas une exigence du pilotage par spécifications)
  • Règles métier : logique de gestion des risques, règles de transaction, règles de facturation
  • Exigences de conformité : classification de sécurité (NIS2 / ISO 27001), transfert transfrontalier de données (RGPD), reporting réglementaire (ACPR, BCE), enregistrement des algorithmes sous l’EU AI Act
  • Charte d’utilisation de l’IA : cas d’usage autorisés, cas nécessitant une validation humaine obligatoire, règles de transfert des données
  • Gouvernance des fournisseurs : clauses contractuelles, mécanismes d’audit, répartition des responsabilités

Annexe : squelette CLAUDE.md version finance (environ 200 lignes, directement forkable)

Voici un squelette de CLAUDE.md destiné à la refonte du système cœur d’une grande banque française, organisé selon l’ordre « principes non négociables → exigences de conformité → charte d’utilisation de l’IA → règles métier → contraintes d’ingénierie ». Pas besoin de repartir de zéro — il suffit de remplir les champs vides avec vos propres règles.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
# CLAUDE.md — <nom du système> — règles de collaboration IA

> Périmètre : <nom du système> v<version>, tous les agents IA (Claude Code / Cursor / Copilot / Codex)
> travaillant sur ce dépôt doivent respecter la présente spécification. Maintenue par le <comité de gouvernance>,
> revue trimestrielle.
> Dernière mise à jour : YYYY-MM-DD

## 1. Présentation du projet
- **Positionnement métier** : nom du système cœur / segments de clientèle / principaux types de transaction
- **Chaîne critique** : transaction → contrôle des risques → compensation → rapprochement → reporting
- **Fenêtre d'indisponibilité** : <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (toute modification interdite)
- **Dépendances amont/aval** : système <X> en amont, système <Y> en aval, plateforme de reporting réglementaire

## 2. Principes non négociables (lignes rouges — toute violation = refus de fusion)

### 2.1 Lignes rouges sécurité
- Mots de passe, clés et jetons passent obligatoirement par le KMS (Key Management Service) — **hardcoding interdit**, **impression dans les logs interdite**
- Les champs sensibles client (numéro national / numéro de carte / CVV / téléphone) **doivent être chiffrés au stockage** ; le texte en clair est proscrit en base
- Les logs ne doivent jamais contenir : numéro national complet, numéro de carte complet, mot de passe en clair, combinaison nom+ téléphone client
- Les appels d'API externes doivent obligatoirement transiter par la passerelle API ; les connexions directes sont interdites

### 2.2 Lignes rouges conformité
- Tout code généré par IA impliquant un accès à des données client doit porter la mention « accès données : <champ> » dans la description de PR
- Les transferts de données transfrontaliers sont interdits ; **toute sortie de données doit passer par une évaluation dédiée** (contacter la conformité)
- Les décisions algorithmiques (crédit / tarification d'assurance / lutte antifraude) doivent conserver une voie de revue humaine
- Tout changement de modèle doit faire l'objet d'un enregistrement d'algorithme ; le numéro d'enregistrement doit être cité dans la PR

### 2.3 Lignes rouges métier
- Toute modification de seuil de contrôle des risques exige la double signature du responsable risques et du responsable métier
- Toute opération impliquant des fonds client doit prévoir un mécanisme d'idempotence + rollback en cas d'échec
- Les limites de transaction, tarifs et paramètres produit passent par la plateforme de gestion des paramètres ; aucun hardcoding dans le code

## 3. Stack technique et contraintes
- **Langages** : Java 17 (cœur) / Kotlin (nouveaux modules) / SQL (base de données)
- **Framework** : Spring Boot 3.x + Spring Cloud
- **Base de données** : PostgreSQL 15 ou équivalent compatible, **clés étrangères interdites**
- **Normes d'interface** : gRPC en interne ; OpenAPI 3.0 pour les interfaces externes ; RESTful réservé aux interfaces d'administration
- **Conventions de nommage** : classes Java en PascalCase, méthodes en camelCase, constantes en UPPER_SNAKE ; tables `t_<domaine>_<entité>` ; index `idx_<table>_<colonne>_<ordre>`
- **Structure de paquets** : `com.<entreprise>.<domaine>.<sous-domaine>.<couche>` (ex. `com.banque.paiements.tx.core.service`)

## 4. Normes de code
- **Couverture de tests minimale** : chaîne critique ≥ 80 %, utilitaires ≥ 60 %, tout nouveau code livré par PR doit être accompagné de ses tests
- **Chemins obligatoirement testés** : tous les controllers doivent disposer de tests d'intégration (y compris les chemins d'échec) ; toutes les branches d'enum doivent disposer de tests unitaires
- **Chemins interdits** : interdiction de modifier le répertoire `<modules d'historique>` — créer d'abord une couche d'adaptation
- **Gestion des dépendances** : tout ajout d'une dépendance tiers passe par une analyse SCA + validation sécurité

## 5. Règles métier (par domaine)
### 5.1 Transactions
- Plafond unitaire : <montant> ; plafond journalier : <montant> ; tout dépassement relève d'une validation manuelle
- Fenêtre de transaction : <HH:MM> ~ <HH:MM>
- Détection de doublons : <fenêtre temporelle> sur le même <champ> = doublon

### 5.2 Contrôle des risques
- Ordre de priorité des listes noires : liste interne → liste réglementaire descendante → gel judiciaire
- Seuil de sortie du modèle antifraude : <score> ; au-delà, double validation humaine obligatoire

### 5.3 Facturation
- Tout changement de tarif doit comporter un numéro de version + une date d'effet
- Les commandes historiques sont calculées au tarif en vigueur à la date d'effet, sans rétroactivité

## 6. Exigences de conformité
- Classification NIS2 / ISO 27001 : <organisme d'évaluation>, <date de la prochaine évaluation>
- Évaluation des transferts transfrontaliers : périmètre (uniquement les modules d'activité transfrontalière)
- Enregistrement des algorithmes (EU AI Act) : périmètre (crédit / tarification d'assurance / autres algorithmes critiques), numéro d'enregistrement `<n°>`
- Reporting réglementaire : table de correspondance des champs ACPR / BCE dans `<chemin>`

## 7. Charte d'utilisation de l'IA
- **Cas d'usage autorisés** : CRUD standard, génération de tests unitaires, brouillons de documentation, suggestions d'optimisation SQL
- **Cas exigeant une revue humaine obligatoire** : logique de contrôle des risques, règles de facturation, gestion des droits, chiffrement / déchiffrement, données transfrontalières
- **Cas interdits en autonomie à l'IA** : dossiers de validation Change Advisory Board (CAB), exécution des changements en production, gestion des incidents
- **Règles de sortie de données** : données d'entraînement / prompts / logs de sortie — aucune sortie hors du pays ; privilégier les déploiements localisés (<fournisseur>)
- **Exigences d'audit** : tout code généré par IA doit porter la mention « assistance IA : <nom de l'outil> » dans la description de PR

## 8. Gouvernance des fournisseurs
- **Admission des fournisseurs** : fourniture obligatoire d'un rapport SOC 2 / ISO 27001 ; les modèles d'IA doivent être accompagnés d'une model card
- **Clauses contractuelles** : propriété des données, explicabilité des modèles, clause de sortie, droit d'audit
- **Mécanisme d'audit** : audit trimestriel de l'usage de l'IA par les fournisseurs ; audit mensuel pour les fournisseurs à risque élevé

## 9. Gouvernance et mise à jour
- **Propriétaire** : <comité de gouvernance> (conformité + sécurité + architecture + métier)
- **Fréquence de mise à jour** : revue trimestrielle ; voie rapide pour les changements urgents (double signature + publication 24 h)
- **Journal des modifications** : voir `CLAUDE_CHANGELOG.md`
- **Traitement des infractions** : 1re infraction = avertissement + formation obligatoire ; 2e infraction = suspension des outils IA ; 3e infraction = retrait des droits

Ce squelette n’est pas une « réponse standard », c’est un « modèle à remplir ». Ce qui compte, ce n’est pas tant la longueur que ce que vous placez dans chaque champ — les blancs qui subsistent révèlent précisément ce que votre organisation n’a pas encore clarifié.

Cas typique : le CLAUDE.md d’une grande banque française a défini des règles spécifiques pour le traitement des mots de passe — dès que le code généré par l’IA implique un mot de passe, il doit obligatoirement appeler l’API interne de gestion des clés, le hardcoding étant interdit. Ce type de règle représente une part importante des motifs de rejet lors des revues de conformité.

Un nouveau champ important au S1 2026 est la définition de Skills / workflows — il ne s’agit plus seulement de documentation, mais d’une chaîne d’outils que l’IA peut invoquer. Le système Skills de Claude Code (entré sur le marché officiel d’Anthropic en février 2026, 112 000 étoiles sur GitHub) transforme des opérations comme « lire un fichier Excel », « générer du SQL » ou « exécuter une migration de données » en workflows partageables. C’est l’évolution clé du pilotage par spécifications au S1 2026 : la norme n’est pas seulement une contrainte, c’est un workflow exécutable.

Phase 3 : institutionnalisation (continue).

Rédiger des normes n’est pas une fin en soi, c’est un point de départ. Encore faut-il les intégrer aux processus de l’organisation :

  • Intégration aux portes CI comme garde-fou : vérification automatique du respect des normes (détection des mots de passe en dur, des champs sensibles non chiffrés, etc.)
  • Configuration partagée d’équipe : utiliser le système Skills pour que toute l’équipe applique le même référentiel
  • Mécanisme de mise à jour périodique : quand les règles évoluent, les normes doivent suivre (revue trimestrielle)
  • Métriques et boucle de rétroaction : suivre le taux de défauts du code généré par IA, le taux de conformité aux revues, le taux de reprise
  • Gouvernance des agents : étendre la gouvernance humaine aux agents IA — c’est précisément ce qu’Atos fait avec Agent 365, en élevant cette gouvernance au niveau « système » plutôt qu’« individu »

EY et Atos ont tous deux fait de la troisième phase une « capacité organisationnelle » au premier semestre 2026. Les 2,5 millions d’heures économisées chez EY sont le fruit d’une exécution correcte des phases 1 et 3 — la phase 2 ne faisait que traduire les règles en documents lisibles par l’IA.

V. Variante sous forte régulation : trois approches d’ingénierie pour intégrer la conformité

Dans les secteurs fortement réglementés — banque, télécommunications, santé — le déploiement piloté par les normes ajoute une contrainte supplémentaire par rapport aux secteurs généralistes : la conformité n’est pas un module externe au processus, elle est intégrée dans le code. Les trois approches ci-dessous, validées au S1 2026, constituent des méthodes éprouvées d’intégration de la conformité, directement exploitables par les DSI et responsables de la transformation numérique lors de la conception organisationnelle.

5.1 Intégrer des référents conformité au sein des équipes stream-aligned : faire de la conformité une présence, pas une validation a posteriori

L’approche traditionnelle : les équipes métier écrivent le code, l’équipe conformité le vérifie après coup — quand un problème est détecté, le code est déjà en production depuis deux semaines, et le coût de reprise est de 2 à 4 semaines. Le problème fondamental, c’est que la conformité intervient en bout de chaîne.

La nouvelle approche : intégrer un référent conformité dans chaque équipe stream (stream-aligned team), selon un modèle de double rattachement — « ligne hiérarchique » vers le département conformité, « ligne fonctionnelle » vers l’équipe métier. Concrètement :

  • Dimensionnement : un référent conformité pour 6 à 8 équipes stream, rattaché au département conformité, mais physiquement installé au sein de l’équipe métier — pas un « détachement » ponctuel
  • Indicateurs fonctionnels : 50 % des objectifs du référent conformité sont alignés sur les indicateurs de l’équipe métier — « taux de défauts de conformité » et « taux de passage au premier contrôle » — et non uniquement sur la « couverture d’audit » du département conformité
  • Intervention en amont : le référent conformité participe aux stand-ups quotidiens (une fois par semaine suffit), aux revues de code (PR), et tout code généré par IA doit passer son feu vert avant fusion — pas après coup, une fois le problème découvert
  • Outillage : le référent conformité s’appuie sur des Skills dédiés à la checklist de conformité, plutôt que sur une vérification manuelle ligne par ligne

Scénario typique : une grande banque française a piloté au premier semestre 2026 trois équipes stream avec des référents conformité intégrés, faisant passer le taux de rejet de conformité du code IA de 35 % à 8 % — le cœur du sujet n’est pas que la conformité « surveille plus strictement », mais qu’elle « surveille plus en amont ». La clé de cette approche réside dans l’alignement des objectifs indirects des référents conformité sur les objectifs métier — si leurs KPI restent dictés uniquement par la direction conformité, l’intégration est vouée à l’échec.

5.2 Faire de la conformité une enabling team : transformer les contraintes en affordances

Approche traditionnelle : l’équipe conformité joue les « gardiens », l’équipe métier la perçoit comme « celle qui complique tout ». Résultat : un jeu à somme nulle.

Nouvelle approche : l’équipe conformité se restructure selon le modèle d’enabling team de Team Topologies — elle n’écrit pas de code, ne révise pas directement les pull requests, mais fournit trois leviers pour permettre à l’équipe métier de « se conformer en autonomie » :

  1. Contrôles de conformité intégrés au pipeline CI : les points de conformité à forte occurrence — mots de passe codés en dur, champs sensibles en clair, transferts transfrontaliers de données, points de décision algorithmique — sont transformés en portes de contrôle obligatoires dans GitHub Actions / GitLab CI. Une PR émanant d’une équipe métier déclenche une vérification automatique ; en cas de non-conformité, le build échoue directement — plus besoin qu’un référent conformité passe manuellement en revue chaque modification.

  2. Exigences réglementaires transformées en affordances (contraintes réactives à l’environnement) : par exemple, lorsqu’un développeur travaille sur une fonctionnalité manipulant des données clients, le plugin IDE affiche une suggestion du type « ce champ devrait appeler le KMS » ; lors de l’écriture de logs, le système détecte automatiquement la présence d’informations sensibles et émet une alerte. L’objectif : faire de la conformité une action naturelle au moment du développement, et non une notification de violation découverte au moment de la mise en production.

  3. Bibliothèque de Skills partagée + formation conformité : l’équipe conformité maintient un ensemble de « Skills conformité » mobilisables dès l’onboarding d’un nouveau collaborateur ou lors d’un changement d’équipe — la connaissance réglementaire passe du statut de « documentation » à celui d’« outil exécutable ».

Scénario type : une banque régionale française a déployé au S1 2026 des contrôles de conformité CI et des alertes IDE, réduisant le temps moyen d’examen de conformité du code IA de 45 minutes à 8 minutes par revue. Le point clé n’est pas que la revue de conformité est devenue plus rapide — c’est que le code généré par l’IA ne commet tout simplement plus l’erreur en amont.

5.3 Conformité à deux vitesses : aligner les niveaux sur le rythme des métiers

Un dernier point : la conformité ne doit pas être appliquée de façon uniforme. Classez les règles en deux niveaux de risque :

  • Règles à haut risque (impliquant les fonds clients / les décisions algorithmiques / les données transfrontalières / les lignes rouges réglementaires) → contrôle strict : revue humaine obligatoire + double vérification par IA + enregistrement auprès du Change Advisory Board (Change Advisory Board (CAB))
  • Règles à faible risque (code CRUD standard / utilitaires / génération de documentation) → contrôle en libre-service : vérification automatique par l’intégration continue (CI), sans revue humaine

Le plan de contrôle d’Agent 365 chez Atos repose précisément sur cette stratification — chaque niveau d’agent est lié à des exigences de gouvernance différentes. En hiérarchisant les règles de conformité par niveau de risque, les équipes métier perçoivent la conformité non plus comme un frein systématique, mais comme un cadre proportionné.

Ce que ces trois éléments signifient ensemble : intégrer la conformité ne revient pas à ajouter une procédure supplémentaire, mais à repenser la structure et les incitations de l’équipe. Si votre direction de la conformité fonctionne encore en mode « contrôle a posteriori », l’adoption du pilotage par spécifications butera sur l’étape la plus difficile : l’institutionnalisation. La direction de la conformité doit d’abord se transformer, pour que le pilotage par spécifications puisse se déployer sans heurts au sein des équipes métier.

VI. Questions que vous pourriez vous poser

« Nous avons déjà des normes de codage. Quelle est la différence ? »

Les normes de codage régissent comment écrire le code ; le pilotage par spécifications régit comment collaborer avec l’IA. Les normes de codage n’incluent pas : les règles métier, les exigences de conformité, ni les politiques d’utilisation de l’IA. Le pilotage par spécifications rend explicite l’ensemble du flux de collaboration homme-IA — ce n’est pas un guide de style de code.

« Écrire des spécifications ne va-t-il pas ralentir le développement ? »

À court terme, oui. À long terme, non. Les données CodeRabbit apportent une réponse sans ambiguïté : le code généré par l’IA sans contraintes présente un risque de défauts environ 1,7 fois plus élevé, et un risque de vulnérabilités de sécurité 2,74 fois supérieur. Dans le secteur bancaire, une seule reprise liée à un contrôle de conformité coûte de 2 à 4 semaines — éviter cette reprise, c’est déjà se payer un mois entier de rédaction de spécifications. Les 250 millions de dollars d’économies réalisés chez EY sont la preuve concrète que cette démarche, une fois institutionnalisée, devient un vrai levier organisationnel.

« Et si personne dans notre équipe ne sait écrire de spécifications ? »

Pas besoin de partir de zéro. GitHub Spec Kit, Claude Code Superpowers et AWS Kiro fournissent tous des modèles prêts à l’emploi. Il vous suffit d’y injecter les règles propres à votre organisation — pour l’essentiel, des règles de conformité et de sécurité. Ces règles existent déjà : les équipes conformité et sécurité les ont rédigées depuis longtemps. Le problème, c’est qu’elles n’ont jamais été mises dans un format que l’IA peut lire.

« Il y a tellement d’outils d’IA sur le marché, lequel choisir ? »

Peu importe. Choisissez ceux que vous utilisez déjà. Le pilotage par spécifications ne dépend pas de l’outil — CLAUDE.md fonctionne aussi bien dans Claude Code, Cursor que Codex ; AGENTS.md tourne dans l’écosystème OpenAI ; constitution.md est indépendant du modèle. L’essentiel, c’est d’écrire les spécifications, pas de changer d’outil. EY déploie dans l’écosystème Microsoft, Atos aussi — les différences d’outillage ne sont que de surface ; c’est l’uniformité de la gouvernance qui fait la vraie différence.

« L’EU AI Act entre pleinement en vigueur en août 2026 — est-ce que ça nous concerne ? »

Oui. L’EU AI Act entre en phase d’application complète le 2 août 2026, avec des exigences de conformité obligatoires pour les systèmes d’IA à haut risque (notamment le crédit, la tarification des assurances, le filtrage des candidatures à l’emploi et les infrastructures critiques) — gestion des risques (Art. 9), gouvernance des données (Art. 10), transparence documentaire (Art. 11 à 13), supervision humaine (Art. 14), exactitude et robustesse (Art. 15). Les amendes peuvent atteindre 35 millions d’euros ou 7 % du chiffre d’affaires mondial. Pour les entreprises françaises et européennes, la mise en conformité est un prérequis opérationnel ; pour les fournisseurs et partenaires hors zone, ses effets de transmission sur les chaînes d’approvisionnement et les activités transfrontalières sont difficiles à contourner (whisperly.ai 2026 ; surecloud.com, juin 2026 ; artificialintelligenceact.eu, juin 2026).

« Comparaison : l’UE régule l’IA, et en France plus spécifiquement ? »

En France, la gouvernance de l’IA générative s’inscrit dans le cadre européen de l’EU AI Act, dont les autorités de référence sont la CNIL (pour la protection des données personnelles et la régulation des systèmes d’IA à haut risque), l’ANSSI (pour la cybersécurité et les opérateurs d’importance vitale — OIV), et le futur AI Office français. La conformité s’articule autour de plusieurs textes : le RGPD (Reg. 2016/679) + la Loi Informatique et Libertés (78-17, révisée en 2024) + l’EU AI Act (Reg. 2024/1689). Pour les secteurs régulés comme la banque, s’ajoutent les exigences de l’ACPR et de la BCE, ainsi que les obligations DORA (Digital Operational Resilience Act, en application depuis janvier 2025). La différence majeure avec l’approche chinoise ne réside pas dans le niveau de détail des dispositions, mais dans la philosophie législative :

DimensionEU AI ActApproche chinoise (Mesures de gestion de l’IA générative)
Positionnement juridiqueRèglement horizontal (applicable à tous les systèmes d’IA)Règle verticale (centrée sur les services d’IA générative)
Niveaux de risque4 niveaux (inacceptable / élevé / limité / minimal)2 niveaux (impliquant la sécurité de l’opinion publique / usage commercial général)
Calage réglementaireEx ante (enregistrement dès la phase de développement)Ex post (enregistrement après mise en service + archivage des algorithmes)
TransparenceÉlevée (publication obligatoire de fiches résumées des sources d’entraînement, model cards)Moyenne (conformité des corpus requise, mais pas de divulgation obligatoire des sources)
Plafond des sanctions7 % du chiffre d’affaires mondial ou 35 M€Suspension du service / amendes (en général multiples des gains illicites)
Champ d’applicationToutes les entreprises dans le seuil de chiffre d’affaires mondialToutes les entités fournissant des services sur le territoire chinois

En pratique, les systèmes d’IA des institutions financières françaises et européennes sont soumis simultanément à plusieurs cadres réglementaires — RGPD + EU AI Act (couche de base) + DORA + exigences sectorielles ACPR / BCE + Loi de Programmation Militaire pour les OIV. Pour faire du pilotage par spécifications dans ce contexte, on ne peut pas se contenter d’une copie d’un cadre unique : il faut articuler « conformité des corpus + enregistrement des algorithmes + reporting réglementaire + résilience opérationnelle » dans le fichier CLAUDE.md, et croiser les contraintes CNIL / ANSSI / ACPR selon les cas d’usage.

Pour les entreprises opérant à l’international, les quatre piliers de l’EU AI Act — « gestion des risques + gouvernance des données + transparence documentaire + supervision humaine » — sont précisément les directions vers lesquelles la plupart des cadres réglementaires convergent progressivement. Rédiger aujourd’hui des normes compatibles avec l’EU AI Act, c’est très probablement se préparer aux durcissements réglementaires des trois prochaines années, en Europe comme ailleurs (CNIL 2025-2026 ; conformité EU AI Act, juin 2026).

VII. Ce que les décideurs doivent en retenir

Enseignement n°1 : rédiger un fichier de spécifications projet CLAUDE.md/AGENTS.md est l’action d’ingénierie au meilleur retour sur investissement à l’ère de l’IA.

Son investissement : 3 à 8 semaines de structuration, plus 1 à 2 semaines de documentation. Son retour : un plafond de risque de défauts multiplié par environ 1,7, une réduction de 2,74 fois des failles de sécurité, et une baisse de plus de 40 % des reprises. Dans le secteur bancaire, éviter une seule reprise liée à un contrôle de conformité (2 à 4 semaines) suffit à couvrir ce coût. Chez EY, le déploiement de Copilot auprès de 150 000 collaborateurs a généré 250 millions de dollars d’économies — à condition d’avoir d’abord établi des spécifications.

Enseignement n°2 : le pilotage par spécifications est une capacité organisationnelle, pas un choix d’outil.

Que vous optiez pour GitHub Spec Kit ou Claude Code importe peu. Ce qui compte, c’est de savoir si vous avez défini « comment notre organisation collabore avec l’IA ». Sans cela, même le meilleur outil ne fera qu’accélérer la production de dette technique.

Enseignement n°3 : intégrez les spécifications dans les processus de l’organisation, ne les laissez pas dépendre des individus.

Si les spécifications ne vivent que dans la tête d’un ingénieur senior, elles disparaissent dès qu’il change d’équipe ou d’entreprise. Elles doivent être matérialisées dans la documentation du dépôt, les portes de validation CI, les configurations partagées d’équipe et les plateformes de gouvernance des agents. Faites des normes un actif organisationnel, pas une compétence individuelle. Les 19 000 agents d’Atos fonctionnent dans 54 pays parce que la gouvernance n’est pas « une question de compétence individuelle », mais « une contrainte systémique ».

Enseignement n°4 : le contrôle vaut mieux que la vitesse.

Les cinq étapes de validation de GitHub Spec Kit, la règle de Superpowers « pas de code avant l’échec des tests », et l’impossibilité de démarrer sans spec chez Kiro — toutes ces approches introduisent un « frein » entre l’IA et le livrable final. Plus l’IA est puissante, plus la gouvernance doit précéder. Le taux d’incidents de 78 % du rapport New Relic 2026 est le prix payé par les 62 % d’équipes qui « publient sans revue ». Les DSI du secteur bancaire le savent mieux que personne : leurs Change Advisory Boards, leurs procédures d’enregistrement des algorithmes et leurs évaluations de sécurité sont tous des contrôles placés avant la mise en production. Le code généré par l’IA appelle les mêmes types de contrôle, et doit les voir intervenir encore plus en amont.

Auto-diagnostic sans complaisance : le code généré par votre IA fait-il souvent l’objet de retours de conformité ? Quel est le dernier incident causé par du code IA ? Si vous demandez à votre responsable technique « comment collaborons-nous avec l’IA ? », peut-il produire un document ? Si vous ne pouvez pas répondre à l’une de ces trois questions, c’est que le pilotage par spécifications n’est pas encore déployé chez vous — écrivez d’abord la spécification, puis achetez l’outil.

Trois questions de coaching pour les décideurs

Pour conclure, trois questions que vous pouvez utiliser directement dans vos échanges avec l’équipe — ce ne sont pas des cases à cocher :

  1. « Si demain tous les outils d’IA étaient débranchés, de combien la qualité du code de votre équipe chuterait-elle ? » — Cette question révèle la vraie valeur des spécifications : si la réponse est « considérablement », c’est que vos spécifications ne sont pas encore ancrées dans les pratiques ; si la réponse est « presque pas », alors le pilotage par spécifications fonctionne déjà.
  2. « Dans votre projet piloté par les spécifications, la conformité joue-t-elle le rôle de “porte-barrière” ou d’”accélérateur” ? » — Si c’est « porte-barrière », votre vitesse d’exécution sera étranglée par les goulots d’étranglement des revues ; si c’est « accélérateur », vous êtes déjà sur la bonne voie décrite dans la section 5.2.
  3. « Dans 12 à 18 mois, comment évoluera la taille de votre équipe ? » — La réponse de Microsoft WTI 2026 est que 82 % des dirigeants utiliseront des agents d’IA pour « étendre » leur main-d’œuvre. Si votre réponse est « elle ne changera pas », soit votre activité ne croît pas, soit votre conception organisationnelle n’a pas suivi le rythme des bénéfices offerts par l’approche par spécifications.

Il n’y a pas de réponse standard à ces trois questions. Mais la direction des réponses importe plus que les réponses elles-mêmes.

Prochaines étapes

Ceci est le sixième article de la série « La transformation de l’ingénierie logicielle à l’ère de l’IA ». Nous sommes partis de la loi de Conway (l’organisation détermine l’architecture), puis avons abordé Team Topologies (comment concevoir l’organisation), ensuite le déplacement des goulots d’étranglement (le goulot se situe dans la validation, pas dans le codage), et aujourd’hui nous avons traité du pilotage par spécifications (utiliser la documentation pour contraindre le comportement de l’IA).

Dans le prochain article (le septième), nous examinerons l’infrastructure sous-jacente qui soutient tout cela — le protocole MCP (Model Context Protocol) : pourquoi le protocole open source publié par Anthropic est surnommé « l’USB-C de l’IA », pourquoi OpenAI, Google et Microsoft s’y sont tous ralliés, et comment il rend possible l’interopérabilité entre outils et agents multiples.

Vous souhaitez transposer ces conclusions dans votre organisation ?

Une fois le pilotage par spécifications entré dans l’entreprise, les questions concrètes qui se posent habituellement sont les suivantes : comment cristalliser les règles clés dans un fichier CLAUDE.md / AGENTS.md, comment compléter les spécifications du code existant, comment intégrer la conformité, et quels indicateurs retenir pour valider un pilote.

Trois formes de collaboration sont proposées aujourd’hui :

  • Formation intra-entreprise : à partir de vos projets réels, structurer les documents de spécification, concevoir les portes CI, définir les chemins d’intégration de la conformité et monter le dispositif de gouvernance.
  • Conseil ciblé : focalisé sur une décision précise — par exemple « notre entreprise doit-elle commencer par rédiger un CLAUDE.md / AGENTS.md ? » — ou sur la hiérarchisation des correctifs de conformité à appliquer au code existant.
  • Conférences et interventions pour le management / en industrie : autour des outils de programmation IA, du pilotage par spécifications, de la gouvernance organisationnelle et des Frontier Firms.

L’article fournit un cadre général. La mise en œuvre concrète nécessite néanmoins une refonte adaptée aux exigences de conformité, aux contraintes réglementaires, à la maturité technique et aux processus de livraison existants de chaque entreprise. Pour toute collaboration, contactez coach@iaiuse.com.

Lecture complémentaire : Méthodologie des enseignes v1.0 (Apprendre l’IA lentement n°187), qui présente en détail le cadre en 7 étapes pour la transformation IA des entreprises.

À propos de cette série

« La transformation de l’ingénierie logicielle à l’ère de l’IA » est une série de recherche en 18 articles destinée aux DSI, CDO, CTO et responsables de la transformation numérique des secteurs des télécommunications, de la finance, de la fabrication et du e-commerce. Elle examine comment les outils de programmation IA, le pilotage par les spécifications et la gouvernance organisationnelle influencent les processus de livraison logicielle, les structures organisationnelles et la maturité technique.

La série suit en continu les publications académiques, les documents des éditeurs et les rapports sectoriels. La base documentaire dépasse les 200 références, et chaque conclusion clé est assortie d’un niveau de preuve, en distinguant les faits vérifiés, les affirmations des éditeurs, les observations du secteur et les déductions de l’auteur.

Fort de près de 8 ans d’expérience en conseil auprès de grandes entreprises et en analyse métier, j’ai travaillé chez IBM sur des projets dans les télécommunications, la finance, l’assurance et la fabrication. J’ai ensuite poursuivi en première ligne sur le développement de produits opérateurs, de produits internet et d’applications IA, dans l’analyse des besoins, la conception produit et le déploiement transverse.

Cette série de réflexions sur la gouvernance normative, l’organisation et l’ingénierie s’appuie sur ces pratiques, croisées avec des recherches publiques et des études de cas sectorielles. Les contenus liés à des projets spécifiques ont été anonymisés ; certains scénarios sectoriels relèvent de la déduction à partir de cas types, et les références correspondantes figurent en fin d’article.

Derrière cette publication, il y a en réalité une petite équipe — moi-même et un ou deux collaborateurs de longue date, chacun en charge d’un volet : recherche sur les outils de programmation IA, analyse de cas de gouvernance organisationnelle, et accompagnement par le coaching. La plupart des projets dont nous disons « nous avons accompagné des entreprises » ont été livrés collectivement par notre équipe. Les limites de confidentialité des clients et les noms propres restent non divulgués ; l’anonymat est préservé pour laisser la place à de futurs collaborateurs.

Références (toutes vérifiées, niveau de preuve indiqué pour chaque entrée)

  • CodeRabbit (décembre 2025). State of AI vs Human Code Generation Report. Les problèmes dans le code généré par l’IA sont 1,7 fois plus nombreux que dans le code écrit par un humain (10,83 contre 6,45 problèmes par pull request), avec un écart de 1,75× sur la logique et l’exactitude, 1,64× sur la qualité du code, 1,57× sur la sécurité, 1,88× sur le traitement des mots de passe et 2,74× sur les failles XSS. Niveau de preuve : primaire. Source : https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263
  • The Register (17 décembre 2025). Couverture du rapport CodeRabbit dans son intégralité : analyse de 470 pull requests open source, les PR assistées par l’IA présentent 10,83 problèmes contre 6,45 pour celles entièrement humaines. Niveau de preuve : secondaire. Source : URL ci-dessus
  • CodeRabbit / David Loker (janvier 2026). « 2026 Predictions: The Speed Trap » — 2026 marque le tournant décisif : on passe de la « vitesse de génération de code » à la « qualité du code et à la gouvernance ». Niveau de preuve : secondaire. Source : https://tfir.io/ai-code-quality-2026-guardrails
  • New Relic (2026). The 2026 State of AI Coding Report. 78 % des équipes constatent davantage d’incidents après la mise en production de code généré par IA ; 62 % des responsables techniques admettent que leurs équipes « publient en confiance, sans revue » du code IA ; 96 % jugent l’observabilité indispensable. Niveau de preuve : primaire (rapport éditeur). Source : https://newrelic.com/resources/report/2026-state-of-ai-coding
  • Rapport annuel Microsoft 2026 Work Trend Index (5 mai 2026). Enquête auprès de 20 000 travailleurs de l’IA, couvrant 10 pays ; 82 % des dirigeants prévoient d’étendre leur main-d’œuvre avec des agents d’IA sous 12 à 18 mois ; 81 % anticipent une intégration moyenne ou importante des agents d’IA ; 24 % ont déjà déployé au niveau entreprise ; 49 % des conversations Copilot soutiennent le travail cognitif ; 58 % des utilisateurs d’IA déclarent accomplir « des choses impossibles il y a un an », un chiffre qui monte à 80 % chez les professionnels de pointe (Frontier Professionals). Niveau de preuve : niveau 1. Source : https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf
  • Rétrospective FY26 de Microsoft : de l’expérimentation IA à la transformation de pointe (28 juillet 2026). EY a déployé Microsoft 365 Copilot auprès de 150 000 employés, générant 2,5 millions d’heures économisées et environ 250 millions de dollars ; l’extension à 400 000 employés dans le monde a permis une accélération de 95 %, une réduction de 37 % des coûts de fonctionnement financier et jusqu’à 90 % de réduction des flux de travail manuels. Atos a déployé Copilot auprès de 56 000 employés dans 56 pays, accompagné de 19 000 agents IA, avec un plan de contrôle unifié couvrant identité, sécurité, conformité et gouvernance. Niveau de preuve : niveau 1 (revue officielle de Microsoft). Source : https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation
  • Atos Group et Microsoft : un partenariat stratégique (9 juin 2026). Atos déploie Microsoft 365 E7 (Frontier Suite) auprès de 56 000 collaborateurs répartis dans 56 pays, ainsi que 19 000 agents IA ; unification de la console de gestion pour les environnements Entra/Defender/Intune/Purview/Agent 365. Niveau de preuve : 1 (communiqué de presse conjoint des deux sociétés). Source : 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 (open source en septembre 2025, évolution au S1 2026). Processus de validation en 5 étapes /speckit.constitution → /specify → /plan → /tasks → /implement, plus /clarify /analyze ; indépendant du modèle (Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code — tous compatibles). Niveau de preuve : 1. Source : https://github.com/github/spec-kit
  • AWS Kiro (sorti en juillet 2025, évolution au S1 2026). Workflow en trois phases : exigences → conception → tâches ; le spec déclenche des actions d’agent prédéfinies ; impossible de démarrer sans spec. Niveau de preuve : 1. Source : https://kiro.dev/
  • OpenAI Codex + AGENTS.md + Skills (2025-2026). Codex dépasse les 5 millions d’utilisateurs actifs hebdomadaires en juin 2026, dont 20 % de non-développeurs ; AGENTS.md + Skills forment un jeu d’instructions composable. Niveau de preuve : primaire (annonce officielle OpenAI). Source : https://developers.openai.com/codex/skills
  • Claude Code (Anthropic, S1 2026). CLAUDE.md + .claude/rules/ + système Skills ; entrée sur le marché officiel Anthropic en février 2026 ; dépôt Skills à 112 000 étoiles sur GitHub ; 2,5 Md$ d’ARR disclosed lors du tour G de février 2026. Niveau de preuve : primaire. Source : https://code.claude.com/docs/en/claude-directory
  • JetBrains AI Pulse Survey (janvier 2026). Enquête menée auprès de plus de 10 000 développeurs professionnels dans le monde, localisée en 8 langues ; CSAT Claude Code de 91 % / NPS de 54 (le plus élevé du secteur) ; taux d’adoption de Claude Code en environnement professionnel de 18 % (multiplié par 6 en 9 mois, passant de 3 %), 24 % en Amérique du Nord ; Copilot adopté à 29 % en environnement professionnel mais croissance stagnante ; Cursor à 18 %. Niveau de preuve : niveau 1. Source : https://www.jetbrains.com/lp/tools/ai-tools/
  • Pragmatic Engineer Newsletter (février 2026). Enquête auprès de 15 000 développeurs ; 46 % désignent Claude Code comme leur outil « préféré », Cursor 19 %, Copilot 9 %. Niveau de preuve : niveau 1. Source : https://newsletter.pragmaticengineer.com/
  • Alibaba Qoder (août 2025 → juillet 2026). Publié par Alibaba en août 2025 ; le 15 mai 2026, Qoder 1.0 est devenu un Autonomous Agent Development Workbench ; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki ; le 28 mai 2026, Cloud Agents (runtime d’agents hébergés) ; le 21 juillet 2026, Qoder Security ; en mai 2026, plus de 5 millions d’utilisateurs dans le monde ; intégration CLI avec Microsoft Teams ; le 20 mai 2026, Tongyi Lima est renommé Qoder CN. Niveau de preuve : primaire. Sources : https://www.alibabacloud.com/en/marketplace/qoder ; https://baike.baidu.com/en/item/Qoder/1427525
  • vibecoding.app / thebcms.com / tfir.io (S1 2026). Commandes en cinq phases de Spec Kit, évaluation comparative des outils SDD, méthode de notation EARS. Niveau de preuve : secondaire (évaluations par des tiers). Source : https://vibecoding.app/blog/spec-kit-review ; https://thebcms.com/blog/spec-driven-development
  • EU AI Act / Code of Practice (application complète au 2 août 2026). Les systèmes d’IA à haut risque doivent être conformes d’ici le 2 août 2026 ; les modèles GPAI existants bénéficient d’un délai jusqu’au 2 août 2027 ; amendes pouvant atteindre 35 millions d’euros ou 7 % du chiffre d’affaires mondial ; articles 9 à 15 : gestion des risques, gouvernance des données, transparence documentaire, supervision humaine, exactitude et robustesse. Niveau de preuve : primaire (règlement + analyse de conformité secondaire). Sources : https://artificialintelligenceact.eu/code-of-practice-overview ; https://www.surecloud.com/resource-hub/eu-ai-act-complete-compliance-guide
  • Rapport Qodo sur l’état de la qualité du code IA (2025). 44 % des problèmes trouvent leur origine dans un manque de contexte. Niveau de preuve : secondaire (rapport de fournisseur). Source : https://www.qodo.ai/reports/state-of-ai-code-quality/
]]> Code IA : 1,7× défauts, 2,74× failles. Cinq plateformes — Spec Kit, Kiro, Codex, Claude Code, Qoder — convergent en 2026 H1 vers le pilotage par spécifications. 【Spec-Driven】Spec-Driven Development——Menulis Spesifikasi adalah Aksi Rekayasa dengan ROI Tertinggi di Era AI Transformasi Rekayasa Perangkat Lunak di Era AI——Belajar AI Perlahan-lahan 177 https://iaiuse.com/id/posts/spec-driven-development-menulis-spesifikasi-adalah-tindakan-rekayasa-roi-tertinggi-di-era-ai 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z

Sumber data dalam artikel ini: CodeRabbit 2025.12 / laporan New Relic 2026, Microsoft Work Trend Index 2026, pengumuman Microsoft FY26 Frontier Firms, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. Studi kasus merupakan ringkasan skenario representatif, tidak merujuk pada perusahaan tertentu.

Kesalahan terbesar Anda bukan tidak membeli tools, tapi tidak menulis CLAUDE.md

Seorang CIO dari bank swasta mengeluh kepada saya: tools AI sudah dibeli, model sudah di-deploy, orang-orang sudah dilatih, tapi selama paruh pertama 2026, delivery cycle nyaris tidak bergerak. Lead tim core system bahkan lebih blak-blakan: “Kode yang ditulis AI memang bisa dipakai, tapi tiap kali harus ditulis ulang—AI-nya tidak paham aturan internal bank kami, tidak paham regulasi kepatuhan, tidak paham cara integrasi dengan sistem lama yang umurnya 30 tahun.”

Masalahnya bukan karena AI kurang canggih, melainkan karena kalian tidak menuliskan aturannya. Analisis CodeRabbit terhadap 470 pull request open-source pada Desember 2025 menghasilkan sejumlah angka yang banyak dikutip: PR kolaborasi AI rata-rata mengandung 10,83 masalah, sedangkan PR murni manual 6,45 — 1,7 kali lipat, 70% lebih banyak bug dibanding manual. Sampai 2026, ceritanya tidak berbalik: New Relic dalam 2026 State of AI Coding Report menemukan bahwa 78% tim melaporkan lebih banyak insiden setelah kode AI dirilis, dan 62% pemimpin teknis mengakui tim mereka “dengan percaya diri langsung mengirim kode AI tanpa meninjaunya baris per baris” (laporan resmi New Relic 2026, skor 0,866, sumber primer). Kedua kumpulan data ini menceritakan hal yang sama — AI tidak kekurangan kemampuan, yang kurang adalah konteks.

Pada titik waktu Agustus 2026 ini, semua narasi “percepatan transformasi AI” harus dilihat dalam satu kerangka perbandingan:

| Kategori | Kemajuan (2026 H1) | Kontra-contoh (2026 H1) |
|—|—|—|—|
| EY | Microsoft 365 Copilot diterapkan ke 150.000 karyawan, menghemat 2,5 juta jam / USD 250 juta; diperluas ke 400.000 karyawan global | Namun juga mengakui bahwa percepatan 95% dan penurunan 37% biaya operasional keuangan hanya berlaku jika “tata kelola diterapkan lebih dulu” |
| Atos | Diterapkan di 54 negara / 56.000 karyawan; menjalankan 19.000 agen AI secara bersamaan, dengan control plane terpadu untuk identitas/keamanan/kepatuhan/tata kelola | Berpegang teguh pada prinsip “naikkan kapabilitas tata kelola Agent 365 dulu, baru skalakan” |
| Microsoft sendiri | Work Trend Index 2026: 82% pemimpin berencana memperluas tenaga kerja dengan agen AI dalam 12–18 bulan | Pada periode yang sama mengakui bahwa “laju perubahan organisasi tertinggal dari adopsi individu” — ini adalah kontradiksi inti dalam konsep Frontier Firm |

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

Dua perbandingan ini menunjukkan satu hal: tanpa tata kelola, scaling sama saja dengan mengalikan risiko dengan N. Yang membuat EY/Atos/Microsoft bergerak “cepat” bukanlah kecepatan modelnya, melainkan karena “organisasi mereka sudah lebih dulu menjawab pertanyaan bagaimana memakai AI”. Inilah latar belakang mengapa Spec-Driven Development (SDD) benar-benar menjadi arus utama di H1 2026 — bukan karena engineer menyukai dokumentasi, tapi karena tanpa menulis spek, mustahil bertahan hidup di lingkungan yang dipenuhi 19.000 agen.

Artikel ini menjabarkan tiga hal: 1) mengapa cacat pada kode buatan AI 1,7 kali lebih parah daripada kode manual; 2) bagaimana lima platform — GitHub, AWS, OpenAI, Anthropic, dan Alibaba — pada H1 2026 bergerak menuju paradigma yang sama: menggunakan dokumentasi untuk mengendalikan perilaku AI; 3) mengapa spec-driven development adalah kapabilitas organisasi, bukan sekadar pilihan tools, serta tiga tahap implementasinya di H1 2026.

AI code vs human code: defect distribution (470 open-source PRs analyzed) CodeRabbit 2025.12 report | all numbers are AI/human multiples (baseline 1.0)

Bar length = AI defects as multiple of human; baseline 1.0× = human level

Baseline 1.0×

Total issues

1.7×
AI 10.83 vs human 6.45 / PR

Logic/correctness errors

1.75×

Code quality/maintainability

1.64×

Security findings (combined)

1.57×

Improper password handling

1.88×

XSS vulnerabilities

2.74×
↑ highest

Unconstrained AI code exceeds human on every dimension
Finance/telecom = compliance reconciliation, password management, sensitive field encryption — AI misses all

I. Tingkat Cacat AI Bukan Masalah Model, tapi Masalah Konteks

Ada satu kalimat dalam laporan CodeRabbit yang sering dikutip: “AI kekurangan logika bisnis lokal: model menyimpulkan pola kode secara statistik, bukan melalui pemahaman semantik. Tanpa batasan yang ketat, mereka akan melewatkan aturan sistem yang telah diinternalisasi oleh engineer senior.”

Kalimat ini menjelaskan mengapa platform pemrograman AI milik CodeRabbit sendiri (perusahaan yang khusus mengerjakan review kode berbasis AI) bisa melihat data ini lebih awal daripada yang lain — mereka memeriksa ribuan pull request setiap hari, dan setiap hari mereka melihat seperti apa kode yang ditulis AI. Temuan yang “paling krusial” bukanlah angka totalnya, melainkan distribusinya:

  • Logika/kebenaran +75%: error logika bisnis, error dependensi, error alur kontrol, error konfigurasi — masalah jenis ini mungkin tidak muncul saat pengujian, tapi bisa menyebabkan insiden di lingkungan produksi.
  • Kualitas kode +64%: penamaan yang tidak konsisten, struktur yang tidak jelas, pelanggaran pola proyek — ini adalah “kategori dengan perbedaan terbesar”. Engineer senior langsung bisa melihat “ini bukan gaya penulisan tim kita”.
  • Keamanan +57% (XSS tertinggi 2,74×): penanganan password yang tidak tepat (1,88×), referensi objek yang tidak aman (1,91×), kebocoran informasi sensitif, deserialisasi yang tidak aman (1,82×) — di industri keuangan, ini bukan soal “bisa dipakai atau tidak”, tapi soal “bisa dirilis atau tidak”.

Masalahnya bukan AI-nya yang kurang canggih. Masalahnya AI tidak bisa melihat.

Kembali ke titik hambatan nyata yang dihadapi CIO tersebut, ada tiga kegagalan konkret AI di sistem inti perbankan:

Pertama, AI tidak bisa melihat logika rekonsiliasi 30 tahun. Aturan manajemen risiko bank tertulis di stored procedure sistem inti—ditulis 30 tahun lalu, tidak ada yang ingat semuanya. Logika kode yang dihasilkan AI tampak benar, tapi di lingkungan produksi akan memicu pemeriksaan rekonsiliasi yang tidak diingat siapa pun itu, menyebabkan seluruh batch transaksi gagal.

Kedua, AI tidak bisa melihat batasan kepatuhan. Password wajib lewat key management system, field sensitif wajib dienkripsi saat disimpan, log tidak boleh mencetak informasi nasabah—ini batasan keras regulasi, tertulis di kebijakan internal. AI tidak tahu, kode yang ditulisnya bisa jalan tapi gagal lolos review kepatuhan.

Ketiga, AI tidak bisa melihat utang teknis Anda. Sistem host berusia 30 tahun itu memakai protokol antarmuka sendiri, dokumentasinya sudah hilang sejak lama. AI menulis kode sesuai standar RESTful umum, setelah rilis baru ketahuan antarmukanya tidak cocok—ulang dua minggu.

Kembali ke angka New Relic yang lain: 62% tim “percaya diri rilis tanpa review” kode AI, 78% melaporkan lebih banyak insiden setelah rilis. Dua angka ini digabungkan, artinya—tingkat cacat kode AI itu sendiri bukan masalahnya; “saya tidak tahu kode AI punya cacat apa” justru masalahnya.

Skenario umum: sebuah bank saham gabungan memperkenalkan AI untuk membantu pengembangan modul kontrol risiko pada sistem inti. Dalam tiga bulan, tingkat penolakan tinjauan kepatuhan meningkat signifikan. Masalah utamanya adalah aturan internal seperti manajemen kata sandi, enkripsi field sensitif, dan kepatuhan log. Aturan-aturan ini tertulis di dokumen internal, tetapi AI tidak dapat melihatnya. Belakangan, tim menulis aturan inti ke dalam CLAUDE.md, dan tingkat penolakan turun drastis.

II. Lima Platform pada H1 2026: “Berbasis Aturan” yang Menuju Arah yang Sama

Pada Juli 2025, GitHub merilis Spec Kit. Pada awal 2026, AWS Kiro, OpenAI Codex, dan Anthropic Claude Code semuanya melengkapinya. Pada Mei 2026, Alibaba Qoder memasukkan “Spec-Driven Workflow” ke dalam positioning produknya. Lima platform besar pada H1 2026 sampai pada paradigma yang sama—menggunakan dokumen untuk membatasi perilaku AI. Ini bukan penemuan dari satu perusahaan, melainkan respons kolektif industri terhadap “krisis kualitas kode AI”.

Five platforms' compliance-driven paths (2025-2026 H1) GitHub Spec Kit Open Source 2025.9 constitution.md Five-stage gating: constitution → specify → plan → tasks → implement Model-agnostic, 8+ agents Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md Three-stage workflow: Requirements → Design → Tasks Spec-driven in IDE workflow Hook-triggered auto agents Compliance/audit hooks prebuilt No spec, no start OpenAI Codex 2025-2026 AGENTS.md + Skills system Composable instruction sets Team-level shared config 5M+ weekly active (2026.6) 20% non-developers From coding to general agents Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + Keterampilan（Toko Resmi 2026.2） + Ekosistem MCP CSAT 91% / NPS 54 $2.5B ARR（2026.2） GitHub 11.2 juta bintang Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Mode Kuesioner Eksekusi Mandiri + Mode Ahli Tim + RepoWiki Konteks 5M+ Pengguna Global（2026.5） 2026.7.21 Qoder Security CLI DingTalk sudah terhubung Paradigma Bersama：Menulis "Bagaimana kita bekerja sama dengan AI" secara eksplisit dalam dokumen, disimpan di repositori Membuat semua orang dan semua agen AI bekerja sama dengan satu set standar yang sama - ini adalah inti dari pengembangan standar

Mari kita lihat satu per satu aksi terbaru setiap platform pada H1 2026:

GitHub Spec Kit: Referensi Implementasi, Gerbang Lima Tahap. Dirilis open source pada September 2025, hingga H1 2026 telah menjadi referensi implementasi industri. 5 perintah inti + 2 pelengkap: /speckit.constitution (prinsip yang tidak bisa dinegosiasikan), /speckit.specify (apa yang akan dikerjakan dan mengapa), /speckit.plan (bagaimana mengubahnya), /speckit.tasks (memecah tugas), /speckit.implement (eksekusi), ditambah /clarify dan /analyze. Desain kuncinya adalah model-agnostic — file spec/plan/tasks yang sama tidak terikat pada agen eksekusi tertentu; Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf, Qwen Code semuanya bisa terhubung. Ini menjadikannya “protokol SDD tingkat organisasi”, bukan produk eksklusif GitHub (ulasan vibecoding.app 2026.6, skor 0.816, sumber sekunder).

AWS Kiro: Menanamkan Specification-Driven Langsung ke IDE. Dirilis Juli 2025, berevolusi menjadi Agent IDE penuh pada H1 2026. Alur kerja tiga tahap: Requirements → Design → Tasks. Bedanya dengan Spec Kit ada di “hooks”—file spec di Kiro bisa memicu aksi agen yang sudah didefinisikan, menanamkan langkah-langkah yang butuh sistem eksternal (seperti kepatuhan, audit, deployment) langsung ke dalam workflow. Kalau mau memaksa tim menulis spec, pilih Kiro—karena kalau kamu nggak nulis spec, Kiro nggak akan jalan (AWS Kiro official 2025.7; Kiro.dev docs 2026).

OpenAI Codex: AGENTS.md + Skills yang Dapat Dikombinasikan. Pada 2025–2026, AGENTS.md didorong menjadi pusat ekosistem pengembangan. Skills adalah perluasan kunci di paruh pertama 2026: alur kerja seperti “membaca file Excel,” “membuat SQL,” dan “menjalankan migrasi data” kini bisa dirangkai sebelumnya, lalu dipanggil seperti menyusun balok Lego. Hingga Juni 2026, pengguna aktif mingguan Codex telah menembus 5 juta, dan 20% di antaranya bukan developer — ini sinyal yang sering terlewat: pendekatan berbasis spesifikasi kini bukan hanya urusan tim engineering, melainkan semua orang. Tim produk, operasional, dan risk management pun ikut menulis AGENTS.md (pengumuman OpenAI, 2 Juni 2026; ulasan thebcms.com, 2026, skor 0.801).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic menyebut dokumen instruksi proyek sebagai CLAUDE.md (masuk pasar resmi Februari 2026), .claude/rules/ (aturan berlapis per direktori), dan Skills (alur kerja yang bisa dibagikan). Claude Code adalah tools dengan tingkat kepuasan developer tertinggi di 2026 H1 — survei JetBrains 2026.1 mencatat CSAT 91% dan NPS 54, didukung dua riset independen (Pragmatic Engineer 2026.2). Ini skor tertinggi di industri AI coding tools saat ini (uvik.net 2026.5, skor 0.956, agregasi sumber primer). Claude Code melesat dari nol ke pendapatan tahunan $2,5 miliar hanya dalam 9 bulan (data putaran Seri G Anthropic, 2026.2), dengan 112 ribu stars di GitHub (repositori Skills) — developer sudah memilih dengan kaki mereka, dan itu membuktikan nilai nyata dari pendekatan berbasis aturan.

Alibaba Qoder: Didorong Regulasi di Pasar Tiongkok. Dirilis pada Agustus 2025, Qoder ditingkatkan ke versi 1.0 pada 15 Mei 2026, resmi bertransformasi dari “AI IDE” menjadi “Autonomous Agent Development Workbench”. Workflow berbasis spesifikasi (Spec-Driven Workflow) ini diluncurkan bersamaan dengan Quest Mode (tugas multi-file otonom), Expert Mode (paralel tim ahli), dan RepoWiki (knowledge graph repositori). Cloud Agents (runtime agen terkelola penuh) hadir pada 28 Mei 2026, disusul Qoder Security (kemampuan kepatuhan keamanan) pada 21 Juli 2026, dan versi Mobile (Android/iOS/HarmonyOS) pada bulan yang sama. Hingga Mei 2026, pengguna globalnya telah melampaui 5 juta, dan DingTalk CLI mencantumkannya sebagai salah satu lingkungan eksekusi agen yang didukung (Yahoo Finance 2025; Alibaba Cloud Official 2026; Baidu Baike 2026.7).

Paradigma Bersama: Tuliskan secara eksplisit “bagaimana kita berkolaborasi dengan AI” sebagai dokumen, simpan di repositori, dan buat semua orang serta semua agen AI bekerja mengacu pada standar yang sama. Kelima platform memiliki detail implementasi yang berbeda (nama file/jumlah tahap/mekanisme hook), tetapi tujuannya persis sama.

Mengapa hal ini terjadi serentak pada H1 2026? Karena ambang batas kemampuan AI sudah terlewati—Claude Code sebagai agen otonom, Codex dengan multi-agen paralel, Cursor untuk refactoring multi-file. AI bukan lagi “alat pelengkapan kode”, melainkan “rekan kerja”. Dokumen orientasi yang Anda berikan untuk rekan baru, harus bisa juga dibaca oleh AI.

III. Standar-Driven adalah Kapabilitas Organisasi, Bukan Pilihan Tools

Ini poin terpenting bagi para pengambil keputusan. Standar-driven bukan soal memilih tools, tapi mendefinisikan “bagaimana organisasi kita berkolaborasi dengan AI”. Mau pakai GitHub Spec Kit atau Claude Code itu tidak penting. Yang penting: apakah Anda sudah menuliskan standar tersebut sebagai dokumen, memasukkannya ke repositori, dan membuat semua orang serta AI bekerja mengacu padanya.

Tanpa ini, tools secanggih apa pun hanya akan membuat tim Anda menghasilkan utang teknis lebih cepat.

Jika kita melihatnya dalam konteks deployment berskala besar pada H1 2026, buktinya jauh lebih kuat. Dalam retrospective FY26 yang dirilis Juli 2026, Microsoft menjadikan studi kasus EY dan Atos sebagai template “Frontier Firm”—bukan karena modelnya baru, melainkan karena kedua perusahaan ini lebih dulu menjawab pertanyaan “bagaimana cara menggunakan AI”:

EY: Governance lebih dulu, skalabilitas menyusul. Sepanjang 2024–2025, EY meluncurkan Microsoft 365 Copilot ke 150.000 karyawan, menghemat 2,5 juta jam dan sekitar US$250 juta. Kuncinya: kerangka tata kelola AI dibangun sebelum deployment. EY menggunakan Power Platform, Copilot Studio, Azure, Foundry, dan Fabric sebagai satu toolchain terpadu, dengan kepatuhan, regulasi, dan audit berada dalam satu fondasi yang sama. Hasilnya baru terlihat kemudian: percepatan 95%, penurunan biaya operasional finance sebesar 37%, dan pengurangan hingga 90% pada alur kerja manual. VP EY menyampaikannya dengan tegas di AI Tour 2026: “Kami tidak menyebarkan AI lalu menambal governance—kami membangun governance dulu, baru menyebarkan AI.”

Atos: Satu Bidang Kendali untuk 19.000 Agen. Atos adalah salah satu organisasi pertama di dunia yang menerapkan Microsoft 365 E7 (Frontier Suite), dengan Copilot yang digunakan oleh 56.000 karyawan di 54 negara. Mereka menjalankan 19.000 agen AI secara bersamaan—mulai dari IT internal, unit bisnis, hingga proyek klien, semuanya dibangun menggunakan Foundry dan Copilot Studio. Kunci keberhasilan Atos adalah “satu bidang kendali”: Entra (identitas) + Defender (keamanan) + Intune (perangkat) + Purview (kepatuhan) + Agent 365 (tata kelola agen), kelima komponen ini terikat menjadi satu kesatuan. Cara pengikatan ini, jika dipetakan ke industri keuangan, setara dengan “kepatuhan keamanan berlapis + penilaian transfer data lintas batas + registrasi algoritma + audit + tata kelola model”—ini adalah arsitektur tata kelola, bukan sekadar alat AI.

Paradoks Perubahan Organisasi ala Microsoft. Dalam laporan 2026 Work Trend Index, Microsoft sendiri mengakui satu hal: “ritme perubahan organisasi tertinggal dari adopsi individu.” Dari 20.000 pengguna AI yang mereka survei, 82% pemimpin berencana memperluas tenaga kerja dengan agen AI dalam 12–18 bulan ke depan, tetapi hanya 24% yang sudah menyelesaikan deployment di tingkat enterprise. 81% pemimpin memperkirakan agen AI akan terintegrasi secara moderat hingga masif ke dalam strategi AI mereka — tetapi lagi-lagi, hanya 24% yang benar-benar sudah melakukannya. Artinya, mayoritas perusahaan masih berada di jarak 12–18 bulan antara “berniat” dan “terwujud.” Pertanyaannya, bagaimana celah ini diisi? Pendekatan berbasis tata kelola (governance) menjadi penopang utamanya.

Sumber: Microsoft FY26 retrospective, 28 Juli 2026; Microsoft 2026 Work Trend Index Annual Report, 5 Mei 2026 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, sumber primer PDF); analisis Futurum Group, 26 Januari 2026 (sumber sekunder).

Implikasi pertama: investasi di tata kelola adalah ROI tinggi.

Data CodeRabbit memberikan dasar perhitungan ROI yang jelas: rasio masalah kode AI sekitar 1,7 kali lipat, kerentanan keamanan turun 2,74 kali lipat. Artinya:

  • Lebih sedikit pengerjaan ulang (di industri keuangan, satu kali review kepatuhan ulang bisa memakan waktu 2-4 minggu)
  • Lebih sedikit insiden keamanan (denda regulasi dan kerugian reputasi akibat satu kebocoran data)
  • Biaya pemeliharaan lebih rendah (pengurangan technical debt 40% adalah angka yang umum)

Menulis spesifikasi proyek CLAUDE.md/AGENTS.md adalah tindakan engineering dengan ROI tertinggi di era AI. Studi kasus EY memberikan konversi dunia nyata—150.000 orang menggunakan Copilot, menghemat USD 250 juta. Perlu dicatat: EY menghemat bukan karena “toolnya hebat”, melainkan karena “spesifikasi berhasil mewujudkan nilai dari tool tersebut.”

Pelajaran kedua: tuangkan spesifikasi ke dalam proses organisasi, jangan bergantung pada individu.

Jika spesifikasi hanya ada di kepala seorang engineer senior, begitu orangnya pindah, semuanya hilang. Spesifikasi harus diendapkan ke:

  • Dokumentasi repository (AGENTS.md / CLAUDE.md / constitution.md)
  • CI gating (memeriksa kepatuhan terhadap spesifikasi secara otomatis)
  • Konfigurasi bersama tim (sistem Skills memungkinkan seluruh tim menggunakannya)

Jadikan standar sebagai aset organisasi, bukan sekadar keterampilan individu. Ini sangat penting di industri keuangan—persyaratan kepatuhan, aturan keamanan, dan aturan bisnis kalian adalah aset tingkat organisasi, bukan sekadar “pengalaman” seorang engineer. 19.000 agen Atos bisa beroperasi di 54 negara karena tata kelolanya bukan soal “siapa yang paham”, melainkan “sistem yang memaksa”.

Pelajaran ketiga: Gerbang kendali (gate) lebih penting daripada kecepatan.

Gerbang kendali lima tahap GitHub Spec Kit (constitution → specify → plan → tasks → implement), aturan Claude Code “tidak menulis kode sebelum tes gagal”, dan Kiro yang “tidak bisa dimulai tanpa spec”—semuanya melakukan hal yang sama: menambahkan “rem” antara AI dan hasil akhir. Setiap langkah memiliki artefak yang bisa diaudit (spec.md, plan.md, tasks.md), dan semuanya bisa diveto atau diubah sebelum kode dibuat.

Semakin otonom AI-nya, semakin butuh gerbang kendali. Change Advisory Board (Change Advisory Board (CAB)) di industri keuangan, proses registrasi algoritma, dan evaluasi keamanan berlapis (dengbao)—pada dasarnya semuanya menambahkan gerbang kendali sebelum produksi. Kode AI juga butuh gerbang kendali serupa, hanya saja bentuknya berbeda. Tim yang 62% “percaya diri mengirim tanpa review” dalam laporan New Relic 2026 itu, sedang membayar mahal kepercayaan diri tersebut dengan tingkat insiden yang lebih tinggi (78%).

Penerapan Standar Industri Keuangan Tiga Tahap（2026 H1 Edisi Praktis） Tahap Pertama：Menghitung Aturan 2-4 minggu｜Paling banyak waktu, ROI tertinggi Daftar Persyaratan Kepatuhan（Pengamanan/ Keluar/ Pendaftaran） Aturan Keamanan（Kata Sandi/ Enkripsi/ Log） Aturan Bisnis (Manajemen Risiko/Transaksi/Penagihan) Batasan Teknis (Antarmuka Lama/Batas Versi) Tata Kelola Vendor (Kontrak/Audit/Tanggung Jawab) Mengumpulkan aturan yang tersebar Menyusun menjadi dokumen terstruktur Tahap Kedua: Masuk ke Repositori 1-2 Minggu | Masuk Repositori, AI Muat Otomatis CLAUDE.md / AGENTS.md constitution.md Definisi Skills (Alur Kerja yang Dapat Dibagikan) Desain Proses Gerbang (Lima Tahap) .claude/rules/ (Aturan Berlapis) Masukkan aturan ke repositori, AI Muat Otomatis Tahap Ketiga: Institusionalisasi Berkelanjutan | Dari Alat Menjadi Kapabilitas Organisasi Gerbang CI (Tinjauan Otomatis) Konfigurasi Berbagi Tim (Skills) Mekanisme Pembaruan Berkala (Tinjauan Kuartal) Metrik (Tingkat Cacat/Tingkat Kepatuhan) Tata Kelola Agen (Agent 365 Tingkat Satu) Standar Menjadi Aset Organisasi, Tidak Bergantung pada Individu

Fase Pertama Paling Memakan Waktu, tetapi ROI Tertinggi
Sebagian Besar Aturan Organisasi Keuangan Tersebar di Dokumen/Email/Otak Manusia, Investasi Pertama 3-8 Minggu

Empat, Tiga Tahap Implementasi Nyata pada H1 2026

Dengan mengambil industri keuangan sebagai contoh, jalur tiga tahap ini juga dapat menjadi referensi bagi industri lain yang memiliki regulasi ketat. Praktik EY dan Atos pada H1 2026 kebetulan sejalan dengan ketiga tahap tersebut.

Tahap Pertama: Inventarisasi Aturan (2–4 minggu).

Ini adalah tahap yang paling memakan waktu, tetapi ROI-nya paling tinggi. Tugasnya adalah mengumpulkan semua aturan yang tersebar di berbagai tempat:

  • Kepatuhan regulasi: baseline minimum untuk industri keuangan = standar keamanan siber BSSN (standar nasional untuk keamanan siber) + penilaian transfer data lintas batas + pendaftaran algoritma di Kominfo (jika satu saja tidak terpenuhi, jangan mulai menerapkan AI), ditambah aturan pelaporan regulasi, perlindungan data nasabah, pembatasan transfer data lintas negara, dan ketentuan data apa saja yang boleh diakses oleh AI
  • Aturan keamanan: manajemen kata sandi, standar enkripsi, penanganan kolom data sensitif, persyaratan log
  • Aturan bisnis: ambang batas manajemen risiko, ketentuan klaim, batasan transaksi, logika penagihan
  • Kendala teknis: antarmuka sistem lama, penamaan basis data, batasan versi framework
  • Tata kelola vendor: bagaimana mewajibkan vendor mematuhi standar kita dalam kontrak, bagaimana mengaudit penggunaan AI oleh vendor

Skenario umum: pada tahap inventarisasi, sebuah perusahaan sekuritas menemukan bahwa aturan-aturan tersebar di banyak dokumen Word, wiki JIRA, email pribadi, dan spreadsheet Excel — baru setelah dirapikan, mereka mendapatkan daftar aturan yang terstruktur. Pendekatan Atos lebih sistematis — mereka langsung memecah aturan ke dalam lima kategori: “kepatuhan, keamanan, bisnis, teknis, vendor”, masing-masing dengan alur kerja tata kelola sendiri, dan terhubung ke bidang kontrol Agent 365.

Ini bukan soal teknis, melainkan soal organisasi — Anda harus membawa departemen kepatuhan, departemen keamanan, dan departemen bisnis ke satu meja, lalu menuliskan aturan yang disepakati semua pihak. Untuk pertama kalinya, organisasi finansial biasanya membutuhkan 3–8 minggu — tetapi ini adalah aset organisasi yang permanen.

Tahap kedua: masukkan ke repositori (1–2 minggu).

Tulis aturan yang telah dirapikan pada tahap pertama menjadi dokumen dan masukkan ke repositori. GitHub Spec Kit menggunakan constitution.md, Claude Code menggunakan CLAUDE.md, OpenAI Codex menggunakan AGENTS.md, dan Alibaba Qoder menggunakan Spec Workflow. Nama file berbeda, tujuannya sama — memastikan AI memuatnya begitu repositori dibuka.

Struktur yang Disarankan (Bentuk Umum untuk Paruh Pertama 2026):

  • Ringkasan Proyek: Sistem ini digunakan untuk apa, dan siapa yang dilayaninya
  • Prinsip yang Tidak Dapat Ditawar: Batas keamanan, batas kepatuhan, batas bisnis
  • Tumpukan Teknologi dan Batasan: Framework apa, database apa, standar antarmuka apa
  • Standar Kode: Konvensi penamaan, struktur direktori, persyaratan minimum cakupan pengujian (tidak mewajibkan ritme TDD—cukup tuliskan persentase cakupan pengujian, jalur yang wajib diuji, dan jalur terlarang; TDD adalah ritme opsional bagi organisasi, bukan kewajiban yang didorong standar)
  • Aturan Bisnis: Logika manajemen risiko, aturan transaksi, aturan penagihan
  • Persyaratan Kepatuhan: standar keamanan siber BSSN (perlindungan berlapis), transfer data lintas batas, pelaporan regulatori, apakah algoritma yang dihasilkan AI perlu pendaftaran
  • Pedoman Penggunaan AI: Skenario apa yang boleh menggunakan AI, skenario apa yang wajib ditinjau manual, aturan transfer data lintas batas
  • Tata Kelola Vendor: Klausul kontrak, mekanisme audit, pembagian tanggung jawab

Lampiran: Kerangka CLAUDE.md Versi Perbankan (sekitar 200 baris, bisa langsung di-fork dan dimodifikasi)

Berikut adalah kerangka CLAUDE.md untuk proyek modernisasi sistem inti bank saham gabungan, yang telah disusun dengan urutan “Prinsip yang Tidak Dapat Ditawar → Persyaratan Kepatuhan → Pedoman Penggunaan AI → Aturan Bisnis → Batasan Teknik”. Perusahaan Anda tidak perlu memulai dari nol—cukup isi slot kosongnya dengan aturan spesifik Anda.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
# CLAUDE.md — <Nama Sistem> Standar Kolaborasi AI

> Cakupan: <Nama Sistem> v<Versi>, semua agen AI (Claude Code / Cursor / Copilot / Codex)
> yang bekerja di repositori ini wajib mematuhi standar ini. Dokumen ini dikelola oleh <Komite Tata Kelola>, ditinjau setiap kuartal.
> Pembaruan terakhir: YYYY-MM-DD

## 1. Gambaran Proyek
- **Posisi Bisnis**: nama sistem inti / segmen pelanggan yang dilayani / jenis transaksi utama
- **Rantai Kritis**: transaksi → manajemen risiko → kliring → rekonsiliasi → pelaporan
- **Jendela Tidak Tersedia**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (dilarang keras melakukan perubahan apa pun)
- **Dependensi Inti**: hulu <Sistem>, hilir <Sistem>, platform pelaporan regulator

## 2. Prinsip Tidak Dapat Ditawar (Garis Merah, Pelanggaran = Penolakan Penggabungan)

### 2.1 Garis Merah Keamanan
- Kata sandi, kunci, dan Token wajib melewati KMS (Key Management Service), **dilarang keras hardcoding**, **dilarang keras mencetak di log**
- Kolom sensitif pelanggan (KTP / nomor kartu / CVV / nomor ponsel) **wajib dienkripsi saat disimpan**, teks polos dilarang masuk basis data
- Log tidak boleh memuat: KTP lengkap, nomor kartu lengkap, kata sandi teks polos, kombinasi nama pelanggan + nomor ponsel
- Pemanggilan API eksternal wajib melewati API Gateway, koneksi langsung dilarang

### 2.2 Garis Merah Kepatuhan
- Kode yang dihasilkan AI yang mengakses data pelanggan wajib mencantumkan label "Akses Data: <Kolom>" di deskripsi PR
- Transfer data lintas batas dilarang, **semua pengiriman data ke luar negeri wajib melalui Penilaian Transfer Data Lintas Batas** (hubungi departemen kepatuhan)
- Keputusan algoritmik (kredit / penetapan harga asuransi / antipenipuan) wajib mempertahankan jalur tinjauan ulang manusia
- Perubahan model wajib melalui Pendaftaran Algoritma, nomor pendaftaran wajib dirujuk di deskripsi PR

### 2.3 Garis Merah Bisnis
- Perubahan ambang batas manajemen risiko memerlukan tanda tangan ganda dari penanggung jawab manajemen risiko + penanggung jawab bisnis
- Operasi yang melibatkan dana pelanggan wajib memiliki desain idempoten + mekanisme rollback saat gagal
- Perubahan batas transaksi, tarif, dan parameter produk melewati platform manajemen parameter, tidak di-hardcode dalam kode

## 3. Tumpukan Teknologi dan Batasan
- **Bahasa**: Java 17 (inti) / Kotlin (modul baru) / SQL (basis data)
- **Framework**: Spring Boot 3.x + Spring Cloud Alibaba
- **Basis Data**: OceanBase 4.x (mode kompatibel MySQL), **dilarang menggunakan foreign key**
- **Standar Antarmuka**: internal wajib gRPC; antarmuka eksternal OpenAPI 3.0; RESTful hanya untuk antarmuka manajemen
- **Konvensi Penamaan**: kelas Java PascalCase, metode camelCase, konstanta UPPER_SNAKE; nama tabel `t_<Domain Bisnis>_<Entitas>`; indeks `idx_<Tabel>_<Kolom>_<Urutan>`
- **Struktur Paket**: `com.<Perusahaan>.<Domain Bisnis>.<Subdomain>.<Lapisan>` (misal `com.bank.pay.tx.core.service`)

## 4. Standar Kode
- **Cakupan Uji Minimum**: rantai kritis ≥ 80%, kelas utilitas ≥ 60%, PR kode baru wajib menyertakan pengujian
- **Jalur Wajib Diuji**: semua controller wajib memiliki integration test (termasuk jalur gagal); semua cabang enum wajib memiliki unit test
- **Jalur Terlarang**: dilarang memodifikasi direktori `<Modul Warisan>` — harus membangun lapisan adaptasi terlebih dahulu
- **Manajemen Dependensi**: penambahan dependensi pihak ketiga wajib melalui pemindaian SCA + persetujuan keamanan

## 5. Aturan Bisnis (per Domain)
### 5.1 Transaksi
- Batas per transaksi: <Jumlah>; batas harian: <Jumlah>; melampaui batas wajib melalui persetujuan manual
- Jendela waktu transaksi: <HH:MM> ~ <HH:MM>
- Penentuan transaksi duplikat: <Jendela Waktu> dengan <Kolom> yang sama dianggap duplikat

### 5.2 Manajemen Risiko
- Prioritas pencocokan daftar hitam: daftar hitam internal → daftar yang diterbitkan regulator → pembekuan yudisial
- Ambang batas output model antipenipuan: <Skor>; jika terlampaui wajib tinjauan ulang manual tingkat dua

### 5.3 Penagihan
- Perubahan tarif wajib memiliki nomor versi + waktu berlaku
- Pesanan historis dihitung berdasarkan tarif yang berlaku pada saat berlaku, tanpa surut-danik

## 6. Persyaratan Kepatuhan
- MLPS Level 3: <Lembaga Penilaian>, <Tanggal Penilaian Berikutnya>
- Penilaian Transfer Data Lintas Batas: cakupan (hanya modul bisnis lintas batas)
- Pendaftaran Algoritma: cakupan (algoritma kunci seperti kredit / penetapan harga asuransi), nomor pendaftaran `<No. Pendaftaran>`
- Pelaporan Regulator: tabel pemetaan kolom CBIRC / Bank Rakyat Tiongkok di `<Jalur>`

## 7. Standar Penggunaan AI
- **Skenario yang Diizinkan Menggunakan AI**: templat CRUD, pembuatan unit test, draf dokumen, saran optimasi SQL
- **Skenario yang Wajib Tinjauan Manual**: logika manajemen risiko, aturan penagihan, kontrol izin, enkripsi/dekripsi, data lintas batas
- **Skenario yang Dilarang Dikerjakan AI Sendirian**: material persetujuan Change Advisory Board (CAB), eksekusi perubahan produksi, tanggap darurat
- **Aturan Data Lintas Batas**: data pelatihan / prompt / log output sama sekali tidak boleh keluar negeri; versi deployment lokal (<Vendor>) diprioritaskan
- **Persyaratan Audit**: semua kode yang dihasilkan AI wajib ditandai "Bantuan AI: <Nama Alat>" di deskripsi PR

## 8. Tata Kelola Vendor
- **Penerimaan Vendor**: wajib menyediakan laporan SOC 2 / ISO 27001; model AI wajib menyediakan model card
- **Klausul Kontrak**: kepemilikan data, interpretabilitas model, klausul keluar, hak audit
- **Mekanisme Audit**: audit penggunaan AI vendor per kuartal; vendor berisiko tinggi diaudit per bulan

## 9. Tata Kelola dan Pembaruan
- **Pemilik**: <Komite Tata Kelola> (kepatuhan + keamanan + arsitektur + bisnis)
- **Frekuensi Pembaruan**: tinjauan per kuartal; perubahan darurat melalui jalur cepat (tanda tangan ganda + pengumuman 24 jam)
- **Log Perubahan**: lihat `CLAUDE_CHANGELOG.md`
- **Penanganan Pelanggaran**: pelanggaran pertama = peringatan + pelatihan wajib; pelanggaran kedua = penangguhan penggunaan alat AI; pelanggaran ketiga = pencabutan hak akses

Kerangka ini bukanlah “jawaban standar”, melainkan “template yang harus diisi”. Apa yang diisi di setiap slot kosong jauh lebih penting daripada seberapa banyak yang ditulis—bagian yang kosong justru memperlihatkan bagian mana dari perusahaan Anda yang “belum dipikirkan matang”.

Contoh tipikal: CLAUDE.md di sebuah bank saham gabungan secara khusus mendefinisikan aturan penanganan password—ketika AI menghasilkan kode yang melibatkan password, kode tersebut wajib memanggil API manajemen kunci internal, dan hardcoding dilarang. Aturan semacam ini menyumbang proporsi yang sangat tinggi dalam alasan penolakan review kepatuhan.

Satu field penting baru di H1 2026 adalah Skills/definisi alur kerja—bukan sekadar dokumen, melainkan rantai alat yang bisa dipanggil oleh AI. Sistem Skills milik Claude Code (masuk ke pasar resmi Anthropic pada Februari 2026, 112 ribu stars di GitHub) mengubah proses-proses seperti “membaca file Excel”, “membuat SQL”, dan “menjalankan migrasi data” menjadi alur kerja yang bisa dibagikan. Ini adalah evolusi kunci dari pendekatan berbasis aturan di H1 2026: aturan bukan sekadar batasan, melainkan alur kerja yang bisa dieksekusi.

Tahap ketiga: Institusionalisasi (berkelanjutan).

Menulis standar bukanlah akhir, melainkan awal. Anda harus mengubahnya menjadi bagian dari proses organisasi:

  • Integrasi gerbang CI: Periksa secara otomatis apakah kode mematuhi standar (misalnya mendeteksi hardcoded password, field sensitif yang tidak dienkripsi)
  • Konfigurasi bersama tim: Gunakan sistem Skills agar seluruh tim dapat memakai standar yang sama
  • Mekanisme pembaruan berkala: Jika aturan berubah, standar pun harus ikut berubah (review kuartalan)
  • Metrik dan umpan balik: Lacak tingkat defek kode AI, tingkat kelulusan review kepatuhan, dan tingkat pengerjaan ulang
  • Tata kelola agen: Perluas tata kelola dari manusia ke agen AI — yang dilakukan Atos di Agent 365 adalah menjadikannya “tingkat sistem” bukan “tingkat individu”

EY dan Atos di H1 2026 sama-sama menjadikan fase ketiga sebagai “kapabilitas organisasi”. Penghematan 2,5 juta jam EY terjadi karena fase pertama dan ketiga dieksekusi dengan benar — fase kedua hanyalah menerjemahkan aturan menjadi dokumen yang bisa dibaca AI.

Lima: Varian Regulasi Ketat: Tiga Pendekatan Rekayasa untuk Menanamkan Kepatuhan

Industri dengan regulasi ketat seperti keuangan, telekomunikasi, dan kesehatan memiliki satu tantangan ekstra dalam implementasi berbasis standar — kepatuhan bukan pelengkap proses, melainkan tertanam dalam kode. Tiga pendekatan di bawah ini adalah cara penanaman kepatuhan yang telah teruji di H1 2026, dan dapat langsung dijadikan referensi oleh CIO/direktur digital saat merancang organisasi.

5.1 Menanamkan Perwakilan Kepatuhan dalam Stream Team: Membuat Kepatuhan “Hadir di Lapangan”, Bukan Sekadar “Menunggu Persetujuan”

Pendekatan tradisional: tim bisnis menulis kode, tim kepatuhan melakukan review setelahnya—saat masalah ditemukan dalam review, kode sudah berjalan di produksi selama dua minggu, dan biaya pengerjaan ulang mencapai 2-4 minggu. Akar masalahnya adalah kepatuhan berada di ujung akhir proses.

Pendekatan baru: tanamkan perwakilan kepatuhan di setiap stream-aligned team, dengan struktur pelaporan ganda—“garis solid” ke departemen kepatuhan dan “garis putus-putus” ke tim bisnis. Desainnya sebagai berikut:

  • Alokasi SDM: 1 perwakilan kepatuhan untuk setiap 6-8 stream team, secara organisasi berada di bawah departemen kepatuhan, tetapi secara fisik duduk bersama tim bisnis—bukan sekadar “pinjaman” ala tugas luar
  • KPI Garis Putus-Putus: 50% bobot KPI perwakilan kepatuhan dikaitkan dengan “tingkat cacat kepatuhan” dan “tingkat lolos review sekali jalan” milik tim bisnis, bukan hanya “cakupan audit” dari departemen kepatuhan
  • Intervensi Dini: perwakilan kepatuhan ikut serta dalam daily stand-up (cukup seminggu sekali), review pull request, dan kode yang dihasilkan AI wajib melewati perwakilan kepatuhan sebelum di-merge—bukan ketahuan setelah merge lalu diperbaiki belakangan
  • Dukungan Tools: perwakilan kepatuhan menggunakan Skills untuk memanggil checklist kepatuhan, bukan memeriksa satu per satu secara manual

5.2 Menjadikan Kepatuhan sebagai Enabling Team: Mengubah Kendala Menjadi Affordance

Pendekatan tradisional: tim kepatuhan berperan sebagai “penjaga gerbang,” sementara tim bisnis menganggap kepatuhan sebagai “pembuat masalah.” Kedua belah pihak berada dalam permainan zero-sum.

Pendekatan baru: tim kepatuhan direstrukturisasi mengikuti pola enabling team dari Team Topologies — tidak menulis kode secara langsung, tidak meninjau pull request secara langsung, tetapi menyediakan tiga hal agar tim bisnis dapat “mematuhi secara mandiri”:

  1. Pemeriksaan kepatuhan dalam pipeline CI: membungkus titik-titik risiko tinggi seperti hardcoded password, penyimpanan plaintext pada field sensitif, transfer data lintas batas, dan titik keputusan algoritma ke dalam gerbang wajib (mandatory gate) di GitHub Actions / GitLab CI. Begitu pull request tim bisnis memicu, sistem otomatis menjalankan pemeriksaan; jika tidak patuh langsung fail — tidak perlu perwakilan kepatuhan menjalankannya secara manual.
  2. Mengubah persyaratan regulatori menjadi affordance (kendala responsif lingkungan): misalnya, ketika fitur yang berkaitan dengan data nasabah dikembangkan, plugin IDE akan memunculkan notifikasi “kolom ini sebaiknya memanggil KMS”; ketika menulis log, secara otomatis mendeteksi apakah memuat informasi sensitif dan mengeluarkan peringatan. Membuat persyaratan kepatuhan menjadi “tindakan yang terjadi secara natural selama proses pengembangan”, bukan “baru diberitahu melanggar aturan apa tepat sebelum peluncuran”.
  3. Perpustakaan Skills bersama + pelatihan kepatuhan: tim kepatuhan mengelola satu set “Skills kepatuhan” yang bisa dipanggil langsung oleh karyawan baru saat orientasi atau saat pindah antar-tim — mengubah pengetahuan kepatuhan dari “dokumen” menjadi “alat yang bisa dieksekusi”.

Skenario tipikal: sebuah bank kota (city commercial bank) di Indonesia pada paruh pertama 2026 menerapkan gerbang kepatuhan CI + notifikasi kepatuhan IDE, menurunkan waktu rata-rata per orang untuk tinjauan kepatuhan kode AI dari 45 menit/tinjauan menjadi 8 menit/tinjauan. Intinya bukan kepatuhan “tinjauan menjadi lebih cepat”, melainkan ketika AI menghasilkan kode, secara inheren “tidak membuat kesalahan”.

5.3 Kepatuhan Dua Kecepatan: Melapisi Aturan agar Selaras dengan Ritme Bisnis

Detail terakhir: kepatuhan tidak boleh diseragamkan dengan “satu ukuran untuk semua”. Bagi aturan ke dalam dua tingkat berdasarkan tingkat risikonya:

  • Aturan berisiko tinggi (melibatkan dana nasabah / keputusan algoritmik / data lintas batas / garis merah keamanan siber) menggunakan pintu gerbang ketat: wajib review manual + konfirmasi kedua oleh AI + pencatatan di Change Advisory Board (Change Advisory Board (CAB))
  • Aturan berisiko rendah (template CRUD / kode perkakas / pembuatan dokumen) menggunakan pintu gerbang layanan mandiri: cukup pemeriksaan otomatis CI, tanpa review manual

Bidang kendali Agent 365 dari Atos pada dasarnya adalah pelapisan semacam ini—agen dengan tingkat berbeda terikat pada persyaratan tata kelola yang berbeda. Dengan melapisi aturan kepatuhan berdasarkan risiko, tim bisnis akan merasakan bahwa “kepatuhan tidak menghambat di mana-mana”.

Skenario tipikal: sebuah bank daerah di Indonesia pada paruh pertama 2026 menerapkan gerbang kepatuhan CI + peringatan kepatuhan IDE, menurunkan waktu rata-rata tinjauan kepatuhan kode AI dari 45 menit per tinjauan menjadi 8 menit per tinjauan. Nilai intinya bukan kepatuhan “tinjauan menjadi lebih cepat”, melainkan ketika AI menghasilkan kode, secara inheren “tidak membuat kesalahan”.

Kesimpulan dari ketiga hal ini secara bersamaan: kepatuhan yang tertanam bukanlah menambah satu proses, melainkan mendesain ulang struktur dan insentif tim. Jika bagian kepatuhan Anda masih dalam mode “review setelah kejadian”, penerapan berbasis aturan akan tersendat di tahap “pelembagaan” yang paling sulit—bagian kepatuhan harus bertransformasi lebih dulu, baru tim bisnis bisa berjalan lancar dengan pendekatan berbasis aturan.

Enam, Pertanyaan yang Mungkin Anda Ajukan

“Kami sudah punya standar pengkodean, apa bedanya dengan ini?”

Standar pengkodean mengatur “cara menulis kode”, sedangkan pendekatan berbasis aturan mengatur “cara berkolaborasi dengan AI”. Standar pengkodean tidak mencakup: aturan bisnis, persyaratan kepatuhan, kebijakan penggunaan AI. Pendekatan berbasis aturan adalah mengeksplisitkan “seluruh alur kolaborasi manusia dan AI”, bukan sekadar panduan gaya kode.

“Apakah menulis standar akan memperlambat kecepatan pengembangan?”

Dalam jangka pendek, ya. Dalam jangka panjang, tidak. Data dari CodeRabbit memberikan jawaban yang jelas: kode AI tanpa batasan memiliki risiko cacat sekitar 1,7 kali lebih tinggi, dan kerentanan keamanan 2,74 kali lebih tinggi. Di industri keuangan, satu kali pengerjaan ulang akibat audit kepatuhan memakan waktu 2-4 minggu — menghemat satu kali pengerjaan ulang saja sudah cukup untuk membayar biaya menulis standar selama sebulan. Penghematan US$250 juta yang dicapai EY adalah bukti nyata bahwa ini bisa menjadi kapabilitas organisasi jika dikelola dengan serius.

“Bagaimana kalau tim kami tidak ada yang bisa menulis standar?”

Tidak perlu memulai dari nol. GitHub Spec Kit, Claude Code Superpowers, dan AWS Kiro semuanya menyediakan template. Anda tinggal mengisi aturan spesifik organisasi Anda — sebagian besar adalah aturan kepatuhan dan keamanan yang sebenarnya sudah lama disusun oleh departemen compliance dan keamanan, hanya saja belum pernah ditaruh di tempat yang bisa diakses oleh AI.

“Banyak sekali tools AI, harus pilih yang mana?”

Tidak penting. Pilih saja yang sudah kalian pakai. Standar yang digerakkan oleh aturan tidak terikat pada alat tertentu — CLAUDE.md bisa dipakai di Claude Code, Cursor, maupun Codex; AGENTS.md berjalan di ekosistem OpenAI; constitution.md tidak bergantung pada model apa pun. Kuncinya adalah menulis standarnya, bukan ganti alat. EY menerapkannya di ekosistem Microsoft, Atos juga menerapkannya di ekosistem Microsoft — perbedaan pilihan alat hanyalah kulit luar; keseragaman tata kelola itulah inti sebenarnya.

“EU AI Act mulai berlaku penuh pada Agustus 2026, apakah ini berdampak pada kita?”

Ada. EU AI Act memasuki tahap implementasi penuh pada 2 Agustus 2026, dengan persyaratan kepatuhan wajib untuk sistem AI berisiko tinggi—termasuk kredit, penetapan harga asuransi, penyaringan tenaga kerja, dan infrastruktur penting—mencakup manajemen risiko (Art. 9), tata kelola data (Art. 10), transparansi dokumentasi (Art. 11–13), pengawasan manusia (Art. 14), serta akurasi dan ketahanan sistem (Art. 15). Denda maksimum mencapai €35 juta atau 7% dari pendapatan global. Bagi perusahaan Tiongkok yang berekspansi ke luar negeri, pasar Uni Eropa adalah ujian wajib; bagi perusahaan domestik, kerangka EU AI Act juga menjadi standar yang paling banyak dirujuk secara global—Anda mungkin tidak wajib mematuhinya secara langsung, tetapi sulit untuk menghindari efek transmisinya terhadap pemasok, mitra, dan operasi lintas batas Anda (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

“Perbandingan domestik: UE mengatur AI, kita mengatur apa?”

Di dalam negeri, tata kelola AI generatif berjalan melalui tiga pilar: “pendaftaran algoritma + pemeriksaan korpus data + penilaian keamanan”, dengan Regulasi Sementara tentang Pengelolaan Layanan AI Generatif yang berlaku sejak Agustus 2023 sebagai instrumen utamanya. Perbedaan terbesar antara keduanya bukan terletak pada ketebalan pasal-pasalnya, melainkan pada filosofi legislatif masing-masing.

DimensiEU AI ActTiongkok “Langkah-Langkah Pengelolaan Layanan AI Generatif”
Posisi HukumRegulasi horizontal (berlaku untuk semua sistem AI)Regulasi vertikal (berfokus pada layanan AI generatif)
Tingkat Risiko4 tingkat (tidak dapat diterima / tinggi / terbatas / minimal)2 tingkat (terkait keamanan opini publik / komersial umum)
Titik PengawasanDi muka (pendaftaran sejak tahap pengembangan)Di belakang (pendaftaran setelah peluncuran + pendaftaran algoritma)
TransparansiTinggi (wajib memublikasikan ringkasan sumber data pelatihan, model card)Sedang (wajib kepatuhan korpus tetapi tidak diwajibkan mengungkapkan sumber)
Batas Denda7% pendapatan global atau €35 jutaPenghentian layanan / denda (biasanya kelipatan dari keuntungan ilegal)
Cakupan PenerapanSemua perusahaan dalam ambang pendapatan globalSemua entitas yang menyediakan layanan di wilayah Tiongkok

Dalam praktiknya, sistem AI di institusi keuangan Indonesia umumnya terikat oleh tiga lapis regulasi sekaligus — UU PDP No. 27/2022 tentang Perlindungan Data Pribadi (lapisan fundamental) + UU ITE 2008/2016 junto PP 71/2019 tentang Penyelenggaraan Sistem Elektronik (lapisan bisnis) + standar keamanan siber BSSN dan regulasi algoritma Kominfo (lapisan kepatuhan). Ini berarti untuk membangun tata kelola berbasis regulasi di Indonesia, kita tidak bisa sekadar menyalin kerangka EU AI Act — ketiga jalur kepatuhan domestik, yaitu “perlindungan data pribadi + pendaftaran algoritma + pelaporan regulatori”, semuanya harus dituangkan ke dalam CLAUDE.md.

Bagi perusahaan Indonesia yang berekspansi ke Uni Eropa: empat pilar EU AI Act — “manajemen risiko + tata kelola data + transparansi dokumentasi + pengawasan manusia” — juga merupakan arah yang secara bertahap diadopsi oleh regulator Indonesia, baik Kominfo maupun BSSN. Beberapa pedoman tata kelola AI yang dikeluarkan Kominfo pada 2025 sudah menunjukkan tingkat granularitas yang serupa dengan standar Eropa, dan Komnas PDP semakin sering menyelaraskan panduannya dengan praktik internasional. Standar yang kompatibel dengan EU AI Act yang Anda tulis hari ini, kemungkinan besar juga akan kompatibel dengan tren regulasi domestik yang semakin ketat dalam 3 tahun ke depan (pedoman AI Kominfo 2025–2026; kepatuhan EU AI Act berlaku Juni 2026).

7. Implikasi bagi Para Pengambil Keputusan

Implikasi pertama: menulis standar proyek dalam bentuk CLAUDE.md/AGENTS.md adalah investasi rekayasa dengan ROI tertinggi di era AI.

Investasinya adalah 3–8 minggu waktu perapihan + 1–2 minggu waktu dokumentasi. Imbalannya: batas atas risiko cacat sekitar 1,7×, kerentanan keamanan turun 2,74×, dan tingkat pengerjaan ulang turun 40%+. Di industri keuangan, menghemat satu kali pengerjaan ulang review kepatuhan (2–4 minggu) saja sudah cukup untuk menutup biaya ini. EY memakai Copilot untuk 150.000 karyawannya dan menghemat USD 250 juta—tapi itu semua berawal dari adanya standar yang jelas.

Pelajaran kedua: Standar adalah kapabilitas organisasi, bukan sekadar pilihan tools.

Mau pilih GitHub Spec Kit atau Claude Code itu tidak penting. Yang penting: apakah kamu sudah mendefinisikan “bagaimana organisasi kita berkolaborasi dengan AI”? Tanpa itu, tools secanggih apa pun hanya membuat tim menumpuk utang teknis lebih cepat.

Pelajaran ketiga: Tuangkan standar ke dalam proses organisasi, jangan bergantung pada individu.

Kalau standar cuma ada di kepala satu engineer senior, begitu orangnya pindah, semuanya hilang. Standar harus dikristalisasi ke dalam dokumentasi repo, CI gating, konfigurasi bersama tim, dan platform tata kelola agen. Jadikan standar sebagai aset organisasi, bukan keterampilan pribadi. 19.000 agen Atos bisa berjalan di 54 negara karena tata kelolanya bukan soal “ada orang yang paham”, melainkan “sistem yang memaksa”.

Pelajaran keempat: Gating lebih penting daripada kecepatan.

Gerbang lima tahap GitHub Spec Kit, prinsip Superpowers “tidak menulis kode sebelum tes gagal”, dan Kiro yang “tidak bisa dijalankan tanpa spec”—semuanya menambahkan “rem” antara AI dan hasil akhir. Semakin kuat kemampuan AI, semakin awal tata kelola harus diterapkan. Angka 78% tingkat insiden dalam laporan New Relic 2026 adalah harga yang dibayar oleh 62% tim yang “rilis tanpa review”. CIO di industri keuangan paling paham hal ini: Change Advisory Board (Change Advisory Board (CAB)), proses pendaftaran algoritma di Kominfo, dan asesmen keamanan siber BSSN—semuanya menambahkan gerbang kendali sebelum produksi. Kode AI juga membutuhkan gerbang kendali serupa, dan harus lebih upfront (lebih di depan).

Self-check terbalik (jangan mempercantik jawaban): apakah kode yang dihasilkan AI di tim Anda sering dikembalikan oleh tinjauan kepatuhan? Masalah apa yang terakhir kali ditimbulkan oleh kode AI? Jika Anda bertanya kepada pemimpin teknis “bagaimana kita berkolaborasi dengan AI”, bisakah dia menunjukkan sebuah dokumen? Jika ada satu saja dari tiga pertanyaan itu yang tidak bisa dijawab, artinya spec-driven belum benar-benar landing — tulis standar dulu, baru beli tools.

Tiga Pertanyaan Pelatih untuk Pengambil Keputusan

Terakhir, tiga pertanyaan—bukan checklist, melainkan bisa langsung Anda gunakan saat berdiskusi dengan tim:

  1. “Jika semua alat AI offline mulai besok, seberapa besar penurunan kualitas kode tim Anda?” — Pertanyaan ini mengungkap nilai nyata dari spec-driven development: jika jawabannya “penurunan signifikan”, berarti spesifikasi Anda belum termaterialisasi; jika jawabannya “hampir tidak berubah”, berarti spec-driven sudah berjalan dengan baik.
  2. “Dalam proyek spec-driven Anda, apakah tim kepatuhan berperan sebagai ‘penjaga gerbang’ atau ‘enabler’?” — Jika jawabannya “penjaga gerbang”, kecepatan implementasi Anda akan terhambat oleh bottleneck review; jika jawabannya “enabler”, Anda sudah berada di jalur yang benar sesuai Bagian 5.2.
  3. “12–18 bulan ke depan, bagaimana ukuran tim Anda akan berubah?” — Jawaban dari Microsoft WTI 2026: 82% pemimpin akan menggunakan AI agent untuk “memperluas” tenaga kerja. Jika jawaban Anda “tidak berubah”, bisa jadi bisnis Anda tidak bertumbuh, atau desain organisasi Anda belum mengikuti dividen dari spec-driven.

Tidak ada jawaban standar untuk ketiga pertanyaan ini. Namun arah jawaban lebih penting daripada jawaban itu sendiri.

Langkah Berikutnya

Ini adalah artikel keenam dalam seri “Transformasi Rekayasa Perangkat Lunak di Era AI”. Dimulai dari Conway (organisasi menentukan arsitektur), berlanjut ke Team Topologies (bagaimana mendesain organisasi), lalu pergeseran bottleneck (bottleneck ada di verifikasi, bukan di penulisan kode), dan hari ini membahas spec-driven (menggunakan dokumentasi untuk mengendalikan perilaku AI).

Artikel berikutnya (ketujuh), kita akan membahas infrastruktur dasar yang menopang semua ini — Protokol MCP (Model Context Protocol): mengapa protokol sumber terbuka dari Anthropic ini disebut sebagai “USB-C untuk AI”, mengapa OpenAI, Google, dan Microsoft semuanya mengikutinya, dan bagaimana protokol ini memungkinkan interoperabilitas multi-alat dan multi-agen.

Ingin Menerapkan Keseluruhan Penilaian Ini di Perusahaan Anda?

Setelah spec-driven masuk ke perusahaan, masalah konkret yang biasanya perlu dipecahkan adalah: bagaimana aturan inti dikristalisasi menjadi CLAUDE.md / AGENTS.md, bagaimana kode yang sudah ada dilengkapi dengan standar, bagaimana kepatuhan ditanamkan, dan indikator apa yang harus dipakai untuk menilai tahap pilot.

Saat ini kami menawarkan tiga bentuk kerja sama:

  • Pelatihan internal perusahaan: dikombinasikan dengan proyek nyata perusahaan Anda, selesaikan perapian dokumen standar, desain gerbang CI, jalur penanaman kepatuhan, dan pembangunan mekanisme tata kelola.
  • Konsultasi khusus: fokus pada satu keputusan yang jelas, misalnya “apakah perusahaan kami harus menulis CLAUDE.md / AGENTS.md dulu”, atau prioritas perbaikan kepatuhan untuk kode yang sudah ada.
  • Berbagi dengan manajemen & pidato industri:mengenai alat pemrograman AI, spec-driven, tata kelola organisasi, dan Frontier Firms.

Artikel ini memberikan kerangka kerja umum. Implementasi spesifik tetap perlu dirancang ulang dengan mempertimbangkan kepatuhan perusahaan, batas regulasi, kematangan rekayasa, dan proses delivery yang ada. Kerja sama dapat menghubungi coach@iaiuse.com.

Bacaan lanjutan: Metodologi Signboard v1.0 (Belajar AI Perlahan-lahan 187), yang memperkenalkan kerangka 7 langkah untuk transformasi AI perusahaan.

Tentang Seri Ini

“Transformasi Rekayasa Perangkat Lunak di Era AI” adalah seri riset yang ditujukan untuk CIO, CDO, CTO, dan pimpinan transformasi digital di industri telekomunikasi, keuangan, manufaktur, dan e-commerce. Seri ini terdiri dari 18 artikel yang berfokus pada bagaimana alat pemrograman AI, dorongan standarisasi, dan tata kelola organisasi memengaruhi proses delivery perangkat lunak, struktur organisasi, dan kematangan rekayasa.

Seri ini terus memantau makalah akademis, materi vendor, dan laporan industri. Basis riset telah mengumpulkan lebih dari 200 referensi, dengan setiap penilaian kunci diberi label tingkat bukti untuk membedakan fakta terverifikasi, klaim vendor, observasi industri, dan penalaran penulis.

Saya memiliki hampir 8 tahun pengalaman konsultasi perusahaan besar dan analisis bisnis, pernah bekerja di IBM dan terlibat dalam proyek-proyek di sektor telekomunikasi, keuangan, asuransi, dan manufaktur. Setelah itu, saya terus berkecimpung di lini depan pengembangan produk operator, produk internet, dan aplikasi AI, menangani analisis kebutuhan, desain produk, dan implementasi lintas tim.

Seri ini tentang keputusan yang digerakkan oleh standar, tata kelola organisasi, dan rekayasa, berasal dari praktik-praktik tersebut, dan divalidasi silang dengan penelitian publik serta studi kasus industri. Konten yang menyangkut proyek spesifik telah dianonimkan; sebagian skenario industri merupakan simulasi masalah tipikal, dan referensi terkait dapat dilihat di bagian sumber di akhir artikel.

Akun ini sebenarnya dijalankan oleh tim kecil—saya dan 1–2 kolega yang bekerja sama dalam jangka panjang, masing-masing menangani riset alat pemrograman AI, studi kasus tata kelola organisasi, dan pendampingan coaching. Sebagian besar proyek yang kami sebut “kami dampingi bersama perusahaan” adalah hasil kerja kolektif kami. Batas kepatuhan klien dan nama individu tetap tidak disebutkan; anonimitas dipertahankan untuk memberi ruang bagi kolaborasi di masa depan.

Referensi (semuanya telah diverifikasi, dengan tingkat bukti yang ditandai per item)

  • CodeRabbit (2025.12). State of AI vs Human Code Generation Report. Kode yang dihasilkan AI memiliki 1,7× lebih banyak masalah dibanding kode buatan manusia (10,83 vs 6,45 masalah/PR), dengan rincian: logika/kebenaran 1,75×, kualitas kode 1,64×, keamanan 1,57×, penanganan password 1,88×, XSS 2,74×. Tingkat bukti: primer. Sumber: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263

  • The Register (2025.12.17). Melaporkan laporan lengkap CodeRabbit: analisis terhadap 470 PR open source menunjukkan PR yang melibatkan kolaborasi AI mengandung 10,83 masalah vs 6,45 masalah pada PR murni manual. Tingkat bukti: sekunder. Sumber: URL yang sama

  • CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap”——2026 adalah tahun transisi dari “kecepatan menghasilkan kode” menuju “kualitas kode dan tata kelola”. Tingkat bukti: sekunder. Sumber: https://tfir.io/ai-code-quality-2026-guardrails

  • New Relic (2026). The 2026 State of AI Coding Report. 78% tim mengalami lebih banyak insiden setelah kode AI diluncurkan; 62% pemimpin teknis mengakui tim mereka “dengan percaya diri mengirim kode AI tanpa review”; 96% menganggap observability sebagai keharusan. Tingkat bukti: primer (laporan vendor). Sumber: https://newrelic.com/resources/report/2026-state-of-ai-coding

  • Microsoft 2026 Work Trend Index Annual Report (2026.5.5). Survei terhadap 20.000 pekerja AI, mencakup 10 negara; 82% pemimpin berencana memperluas tenaga kerja dengan AI agent dalam 12–18 bulan ke depan; 81% memperkirakan integrasi AI agent pada tingkat sedang hingga besar; 24% telah menerapkan di tingkat enterprise; 49% percakapan Copilot mendukung pekerjaan kognitif; 58% pengguna AI berhasil melakukan hal-hal yang “tidak mungkin dilakukan setahun lalu”, dan angka ini naik menjadi 80% di kalangan Frontier Professionals. Tingkat bukti: Level 1. Sumber: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf

  • Retrospektif FY26 Microsoft: Dari Eksperimen AI Menuju Transformasi Kelas Dunia (28 Juli 2026). EY menerapkan Microsoft 365 Copilot untuk 150.000 karyawan, menghemat 2,5 juta jam dan sekitar 250 juta dolar AS; kemudian diperluas ke 400.000 karyawan global, dengan 95% percepatan proses, 37% penurunan biaya operasional finansial, dan pengurangan hingga 90% alur kerja manual. Atos menerapkan Copilot ke 56.000 karyawan di 56 negara, ditambah 19.000 agen AI, dengan satu bidang kendali terpadu untuk identitas, keamanan, kepatuhan, dan tata kelola. Tingkat bukti: Level 1 (retrospektif resmi Microsoft). Sumber: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Kolaborasi Strategis Atos Group dan Microsoft (2026.6.9). Atos menerapkan Microsoft 365 E7 (Frontier Suite) untuk 56.000 karyawan di 56 negara, plus 19.000 agen AI; menyatukan bidang kontrol Entra/Defender/Intune/Purview/Agent 365. Tingkat bukti: Level satu (siaran pers bersama kedua pihak). Sumber: 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 (dirilis open source Sep 2025, berkembang H1 2026). Gerbang 5 tahap /speckit.constitution → /specify → /plan → /tasks → /implement, ditambah /clarify /analyze; agnostik model (Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code semuanya bisa terhubung). Level bukti: tingkat satu. Sumber: https://github.com/github/spec-kit

  • AWS Kiro (dirilis Juli 2025, berkembang H1 2026). Alur kerja tiga tahap: kebutuhan → desain → tugas; spec memicu aksi agen yang telah ditentukan sebelumnya; tanpa menulis spec, tidak bisa dijalankan. Level bukti: tingkat satu. Sumber: https://kiro.dev/

  • OpenAI Codex + AGENTS.md + Skills (2025-2026). Codex 2026.6 mencapai 5 juta+ pengguna aktif mingguan, 20% di antaranya non-developer; AGENTS.md + Skills sebagai set instruksi yang dapat dikombinasikan. Tingkat bukti: Level 1 (pengumuman resmi OpenAI). Sumber: https://developers.openai.com/codex/skills

  • Claude Code (Anthropic, 2026 H1). Sistem CLAUDE.md + .claude/rules/ + Skills; memasuki pasar resmi Anthropic pada 2026.2; repositori Skills di GitHub meraih 112 ribu bintang; pengungkapan Putaran G 2026.2 menunjukkan pendapatan tahunan sebesar USD 2,5 miliar. Tingkat bukti: Level 1. Sumber: https://code.claude.com/docs/en/claude-directory

  • JetBrains AI Pulse Survey (2026.1). Survei terhadap 10.000+ developer profesional secara global, dilokalkan dalam 8 bahasa; CSAT Claude Code 91% / NPS 54 (tertinggi di industri); adopsi Claude Code di tempat kerja 18% (naik 6x lipat dari 3% dalam 9 bulan), di Amerika Utara 24%; Copilot 29% adopsi di tempat kerja namun pertumbuhannya stagnan; Cursor 18%. Tingkat bukti: Tier 1. Sumber: https://www.jetbrains.com/lp/tools/ai-tools/

  • Pragmatic Engineer Newsletter (2026.2). Survei terhadap 15.000 developer; 46% memilih Claude Code sebagai “paling disukai”, Cursor 19%, Copilot 9%. Tingkat bukti: Tier 1. Sumber: https://newsletter.pragmaticengineer.com/

  • Alibaba Qoder (2025.8 → 2026.7). Dirilis oleh Alibaba pada 2025.8; pada 2026.5.15, Qoder 1.0 ditingkatkan menjadi Autonomous Agent Development Workbench; mencakup Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; pada 2026.5.28 meluncurkan Cloud Agents (runtime agen terkelola); pada 2026.7.21 merilis Qoder Security; per Mei 2026, pengguna global mencapai 5 juta+; terintegrasi dengan CLI DingTalk; pada 2026.5.20, Tongyi Lima berganti nama menjadi Qoder CN. Tingkat bukti: primer. Sumber: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525

  • vibecoding.app / thebcms.com / tfir.io (2026 H1). Perintah lima tahap Spec Kit, perbandingan ulasan alat SDD, metode notasi EARS. Tingkat bukti: sekunder (ulasan pihak ketiga). Sumber: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development

  • EU AI Act / Code of Practice (berlaku penuh 2.8.2026). Batas kepatuhan untuk sistem AI berisiko tinggi adalah 2.8.2026; model GPAI yang sudah ada diberi perpanjangan hingga 2.8.2027; denda maksimum €35 juta atau 7% pendapatan global; Art. 9–15 mencakup manajemen risiko, tata kelola data, transparansi dokumentasi, pengawasan manusia, serta akurasi dan ketangguhan. Tingkat bukti: Level 1 (regulasi + analisis kepatuhan sekunder). Sumber: 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). 44% akar masalah berasal dari kurangnya konteks. Tingkat bukti: Level 2 (laporan vendor). Sumber: https://www.qodo.ai/reports/state-of-ai-code-quality/

]]> Defect kode AI 1,7x, kerentanan 2,74x—AI tidak melihat aturan Anda. Spec Kit, Kiro, Codex, Claude Code, Qoder beralih ke spec-driven 2026 H1: tulis CLAUDE.md. 【規範駆動】Spec-Driven Development——仕様書を書くことはAI時代で最もROIが高いエンジニアリング行動 AI時代のソフトウェアエンジニアリング変革——ゆっくり学ぶAI177 https://iaiuse.com/ja/posts/%E4%BB%95%E6%A7%98%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA-%E4%BB%95%E6%A7%98%E6%9B%B8%E4%BD%9C%E6%88%90%E3%81%AF-ai%E6%99%82%E4%BB%A3%E3%81%A7roi%E6%9C%80%E9%AB%98%E3%81%AE%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E8%A1%8C%E5%8B%95-ai%E6%99%82%E4%BB%A3%E3%81%AE%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E5%A4%89%E9%9D%A9 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z

データソース：CodeRabbit 2025.12 / New Relic 2026 報告、Microsoft Work Trend Index 2026、Microsoft FY26 Frontier Firms 公告、GitHub Spec Kit、AWS Kiro、OpenAI Codex、Claude Code、Alibaba Qoder、JetBrains 2026.1 AI Pulse。 以下のケースは代表的なシナリオの総合であり、特定の企業を指していない。 # 最大の間違いはツールを買わなかったことではなく、CLAUDE.md を書かなかったことである。 一つの株式制銀行の CIO が私に愚痴をこぼした：AI ツールを購入し、モデルを展開し、人を訓練したが、2026 年上半期に交付サイクルはほとんど変化しなかった。 核心システム部門の責任者はさらに直接的に言った：「AI が書いたコードは使用できるが、毎回それを書き直す必要がある。なぜなら、それは私たちの銀行のルールを理解しておらず、規制要件を理解しておらず、30 年の歴史を持つ古いシステムとの連携方法を理解しておらず、」

この記事では、以下の3つのことを明らかにします。

1）AIコードの欠陥が人間の欠陥よりも1.7倍以上深刻な理由
2）GitHub、AWS、OpenAI、Anthropic、Alibabaの5つのプラットフォームが2026年上半期にどのように同一のパラダイムに到達したか——文書によってAIの行動を制約する
3）規範駆動が組織能力であり、ツールの選択ではないこと、そして2026年上半期の導入の3つの段階

AIコード vs 人間コード：欠陥分布（470件のオープンソースPR分析） CodeRabbit 2025.12レポート｜全数値はAI／人間の倍率比（基準線1.0）

バーの長さ＝AI欠陥が人間の何倍か；基準線1.0×＝人間レベル

基準1.0×

総問題数

1.7×
AI 10.83 vs 人間 6.45 / PR

論理・正確性エラー

1.75×

コード品質・保守性

1.64×

セキュリティ検出（総合）

1.57×

パスワード不適切処理

1.88×

XSS脆弱性

2.74×
↑ 最高

規範制約なしのAIコードは、全次元で人間を上回る
金融・通信＝コンプライアンス照合、パスワード管理、機密フィールド暗号化、AIは全て見えない

慢慢学AI001: AI 缺陷率不是模型问题，是上下文问题

CodeRabbit の報告では、次の文が繰り返し引用されている。「AI 缺乏本地業務ロジック：モデルは統計推論に基づいてコードパターンを生成するが、意味理解を実現していない。厳格な制約がなければ、資深エンジニアが内在化したシステム規則を無視する。」

この文は、CodeRabbit 自身の AI コードレビュープラットフォーム（AI が生成したコードをレビューする会社）がこのデータを早期に発見した理由を説明している。「最も重要な発見は、総数ではなく分布である。」

  • **論理的正当性 +75%**：ビジネスロジックのエラー、依存関係のエラー、制御フローのエラー、構成エラー。これらの問題はテストでは露呈しないが、生産環境で事故を引き起こす。
  • **コードの品質 +64%**：命名の不一致、構造の不明瞭、プロジェクトのパターンを破ったもの。これは「最大の差異のカテゴリ」である。資深エンジニアは一目で「これは私たちの書き方ではない」と判断する。
  • セキュリティ +57%（XSS の最高 2.74 倍）：パスワードの処理が不当（1.88 倍）、不安全なオブジェクト参照（1.91 倍）、機密情報の漏洩、不安全な逆シリアライズ（1.82 倍）。金融業界では、これは「使えるかどうか」ではなく、「配信できるかどうか」である。

典型シナリオ： 某地方銀行がAIを導入してコアシステムの風險管理モジュールを開発したところ、3ヶ月以内にコンプライアンス審査の却下率が大幅に上昇した。主な問題は、パスワード管理、機密フィールドの暗号化、ログのコンプライアンスなどの内部ルールであった。これらのルールはすべて内部ドキュメントに記載されていたが、AIはこれらを参照できなかった。後にチームはコアルールをCLAUDE.mdに記述し、却下率が大幅に低下した。 # 2. 5大プラットフォームの2026年上半期：異なる道を歩む”規範駆動” 2025年7月、GitHubはSpec Kitを公開し、2026年初頭にはAWS Kiro、OpenAI Codex、Anthropic Claude Codeがすべて補完された。2026年5月、Alibaba Qoderは「Spec-Driven Workflow」を製品の位置付けに書き込んだ。5大プラットフォームは2026年上半期に同じパラダイムに到達した。AIの動作をドキュメントで制約する。これはどの会社の発明でもなく、「AIコード品質危機」に対する業界の集団的な対応である。
五大プラットフォームの規範駆動パス（2025-2026 H1）

GitHub Spec Kit オープンソース 2025.9 constitution.md 五段階ゲート： constitution → specify → plan → tasks → implement モデル非依存、8+ エージェント対応 Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md 三段階ワークフロー： 要件 → 設計 → タスク spec駆動をIDEワークフローに統合 フック起動の自動エージェント コンプライアンス/監査フックを事前配置 spec未記述では起動不可 OpenAI Codex 2025-2026 AGENTS.md + Skills システム 組み合わせ可能な命令セット チーム共有設定 週間アクティブ500万+（2026.6） 非開発者20% プログラミングから汎用エージェントへ Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + Skills（公式マーケット 2026.2） + MCP エコシステム CSAT 91% / NPS 54 $2.5B ARR（2026.2） GitHub 11.2万スター Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Quest Mode 自律実行 + Expert Mode チーム + RepoWiki コンテキスト 5M+ グローバルユーザー（2026.5） 2026.7.21 Qoder Security 钉钉 CLI 接続済み 共通パラダイム：「AIとの協働方法」を明示的にドキュメント化し、リポジトリに配置 全員と全AIエージェントが同一の規範に従って作業——これが規範駆動の本質 それぞれのプラットフォームの2026年上半期の最新動向を詳しく見てみましょう。

GitHub Spec Kit：参考実装、5段階の門戸制御。 2025年9月にオープンソース化され、2026年上半期には業界の参考実装となった。5つのコアコマンド + 2つの補足：/speckit.constitution（交渉不可能原則）、/speckit.specify（何をどうして行うのか）、/speckit.plan（どう変更するか）、/speckit.tasks（タスクの分解）、/speckit.implement（実行）、さらに /clarify と /analyze を追加。キーポイントはモデル非依存であること——同一のspec/plan/tasksファイルが実行エージェントに依存しない。Claude Code、Copilot、Cursor、Codex CLI、Gemini CLI、opencode、Windsurf、Qwen Code などがすべて接続可能。これにより、GitHub専属の製品ではなく、「組織レベルのSDDプロトコル」となった（vibecoding.app評価 2026.6、0.816スコア、二次ソース）。

AWS Kiro：IDE に規範を刻み込む 2025 年 7 月にリリースされ、2026 年上半期には Agent IDE として完成した。3 つのステージで構成されるワークフロー：要件 → 設計 → タスク。Spec Kit との違いは「フック」にあり、Kiro の spec ファイルは事前に定義されたエージェント アクションをトリガーし、合規性/監査/デプロイなどの外部システムが必要なステップをワークフローに埋め込むことができる。チームに規範を書かせたい場合は、Kiro を選択する必要がある——規範を書かないと、Kiro は起動しないから（AWS Kiro 公式 2025.7；Kiro.dev ドキュメント 2026）。

OpenAI Codex：AGENTS.md + 組み合わせ可能なSkills

2025〜2026年、OpenAIはAGENTS.mdをエコシステムの中核に押し出した。Skillsは2026年上半期のキー拡張である：「Excelシートを読む」「SQLを生成する」「データ移行を実行する」といったワークフローを事前にレゴブロックのように組み立てておき、呼び出して使う。Codexの週次アクティブユーザー数は2026年6月にすでに500万を突破し、そのうち20%は非開発者である——これは見過ごされがちなシグナルだ：規範駆動はもはやエンジニアリングチームだけの問題ではなく、プロダクト、運用、リスク管理などの部門も含め全員がAGENTS.mdを書く、全員参加型の課題になっている（OpenAI 2026.6.2発表；thebcms.com評価2026、0.801点）。

注：AGENTS.mdはOpenAI Codexの機能であり、ユーザーがカスタマイズされたワークフローを作成・管理できるようにする。SkillsはCodexの拡張であり、よく使うワークフローを事前に準備しておくことを可能にする。

Claude Code：CLAUDE.md + .claude/rules/ + Skills。

Anthropic はプロジェクトの指示文書を CLAUDE.md（2026 年 2 月に公式マーケットに進出）.claude/rules/（ディレクトリ分割のルール）と呼び、Skills（共有可能なワークフロー）を提供しています。Claude Code は 2026 年上半期に開発者の満足度が最高のツールです——JetBrains 2026.1 の調査結果によると、CSAT は 91%、NPS は 54 です。2 つの独立した調査（Pragmatic Engineer 2026.2）でも同様の結果が得られています。これは、現在の AI プログラミングツール市場で最高のスコアです（uvik.net 2026.5、0.956 スコア、一級源の総合）。Claude Code は 9 か月で 0 から 25 億ドル年間収益（2026.2 Anthropic G ラウンドの口径）に達し、GitHub では 11.2 万のスター（Skills リポジトリ）を獲得しました——開発者が足で投票した結果は、規範主導の真の価値を示しています。

Alibaba Qoder：中国市場の規範駆動。 2025 年 8 月にリリースされ、2026 年 5 月 15 日にバージョン 1.0 にアップグレードされ、正式に “AI IDE” から “Autonomous Agent Development Workbench” にアップグレードされた。Spec-Driven Workflow は、Quest Mode（自律的なマルチファイルタスク）、Expert Mode（専門家チームによる並行処理）、RepoWiki（リポジトリの知識グラフ）とともにリリースされた。2026 年 5 月 28 日に Cloud Agents（完全に管理されたエージェントのランタイム）がリリースされ、7 月 21 日に Qoder Security（コンプライアンスとセキュリティ機能）がリリースされ、同月に Mobile 版（Android/iOS/鸿蒙）がリリースされた。2026 年 5 月までに、世界中のユーザー数は 500 万を超え，钉钉 CLI はそれをサポートするエージェント実行環境の一つとしてリストしている（Yahoo Finance 2025；Alibaba Cloud 公式 2026；Baidu Baike 2026.7）。

共同のパターン：AIと協力する方法を明示的に文書化し、すべての人が同じ規範で働くようにする

5つのプラットフォームは実装の詳細は異なります（ファイル名/ステージ数/ハック機制）が、目標は完全に一致しています。

なぜこのことが2026年H1に集中して起こるのか？それはAI能力の門槍が過ぎ去ったからです。Claude Codeの自律代理、Codexの多代理並列、Cursorの多ファイル再構成、AIはもう「補完ツール」ではありません。同僚です。新しい同僚の入社文書を渡すことができるなら、AIにも渡すことができるはずです。

三、規範ドライブは組織の能力、ツールの選択ではありません

このことは、決断者にとって最も重要なことです。規範ドライブはツールの選択ではありません。組織がAIと協力する方法を定義することです。 GitHub Spec Kitを選んだり、Claude Codeを選んだり重要ではありません。重要なのは、規範を文書化し、倉庫に置き、すべての人がAIと同じ規範で働くようにすることです。

規範がなければ、どれだけの良いツールでも、チームがより速く、より多くの債務を負うだけです。

2026 年の H1 の規模化展開を考えてみましょう。Microsoft は 2026 年 7 月の FY26 回顧録で、EY と Atos の 2 つのケースを「フロントイアーズ企業」(Frontier Firm) テンプレートに記載しました。これは、モデルが新しいことではなく、どちらも「AI をどのように使用するか」という質問に先に答えたからです。

EY のケース

EY は 2024-2025 年に Microsoft 365 Copilot を 150 万人に展開し、250 万時間、約 25 億ドルのコストを節約しました。AI 治理枠組みが先に構築されることが前提でした。EY は Power Platform、Copilot Studio、Azure、Foundry、Fabric を統合したツールチェーンを構築し、規範、合理性、審査を同じ基盤に置きました。これにより、後続の 95% の高速化、37% の財務運営コストの削減、最大 90% の手作業ワークフローの削減が実現しました。EY の副社長は 2026 年の AI Tour で「私たちは先に治理を補充し、次に AI を展開するのではなく、先に治理を補充し、次に AI を展開する」と述べました。

関連リンク

  • Microsoft 365 Copilot
  • EY
  • Atos
  • Frontier Firm

Atos：19,000 のエージェントを統合管理する統合コントロールプレーン

Atos は、Microsoft 365 E7（フロンティアスイート）を世界で初めて導入した組織で、Copilot を 54 国 56,000 名の従業員に展開しました。同時に、19,000 の AI エージェントを稼働——内部 IT、ビジネス部門、顧客プロジェクトまで、すべてのエージェントは Foundry + Copilot Studio で構築されました。Atos がこのことを実現したのは、「統合コントロールプレーン」——Entra（アイデンティティ）+ Defender（セキュリティ）+ Intune（デバイス）+ Purview（コンプライアンス）+ Agent 365（エージェント管理）——これら 5 つの機能を統合したことです。この統合は、金融業界では「等保 + データ出境 + アルゴリズム登録 + 検査 + モデル管理」という意味になります。これは、管理構造である治理アーキテクチャであり、単なる AI ツールではありません。

注：

  • Entra は、Atos のアイデンティティ管理プラットフォームです。
  • Defender は、Atos のセキュリティプラットフォームです。
  • Intune は、Atos のデバイス管理プラットフォームです。
  • Purview は、Atos のコンプライアンス管理プラットフォームです。
  • Agent 365 は、Atos のエージェント管理プラットフォームです。

Microsoft の “組織変革のジレンマ”。 2026 年の Work Trend Index 報告では、Microsoft 自身が認めた事実が存在する。「組織変革のペースは個人利用と遅れている」。調査に参加した 20,000 人の AI 使用者のうち、82% のリーダーは、12-18 か月以内に AI 代理を使用して労働力を拡大する予定であるが、24% の企業がすでに企業レベルで実装している。また、81% のリーダーは、AI 代理が中程度または大量に AI戦略に組み込まれると予想しているが、同様に24% の企業がすでに実装している。これは、ほとんどの企業が「準備」から「実行」までの 12-18 か月の間隔を埋める必要があることを意味し、規範化は主な焦点となる。

参考文献：

  • Microsoft FY26 2026.7.28 回顧録
  • Microsoft 2026 Work Trend Index 年次報告書 2026.5.5（assets-c4akfrf5b4d3f4b7.z01.azurefd.net、PDF 一級源）
  • Futurum Group 2026.1.26 分析（二級源）

教訓一：規範化投資は高 ROI。

CodeRabbitのデータは、ROIを計算する明確な根拠を示している。AIによるコード問題発生率は約1.7倍、セキュリティ脆弱性は2.74倍減少する。つまり、こういうことだ：

  • 手戻りの削減（金融業界では、コンプライアンス審査の手戻り1回で2〜4週間かかる）
  • セキュリティインシデントの減少（データ漏えい1件で、規制罰金と風評被害が発生する）
  • 保守コストの低減（技術負債が40%減るのはよくある数字だ）

CLAUDE.md / AGENTS.md にプロジェクト規範を書くことは、AI時代において最もROIの高いエンジニアリング施策だ。EYの事例は現実世界での換算値を示している——15万人にCopilotを展開し、2億5,000万ドルを節約した。ここで重要なのは、EYが「ツールが優れていたから」節約できたわけではない。「規範によってツールの価値が具現化された」からだ。

示唆その2：規範は個人ではなく、組織のプロセスに組み込む。

規範がベテランエンジニアの頭の中にしか存在しない場合、人が異動すれば消えてしまう。必ず以下に定着させるべきだ：

  • リポジトリのドキュメント（AGENTS.md / CLAUDE.md / constitution.md）
  • CIゲート（規範の遵守状況を自動チェック）
  • チーム共有の設定（Skillsシステムで全チームが利用可能にする）

規範を個人のスキルではなく、組織の資産にする——これは金融業界では特に重要だ。コンプライアンス要件、セキュリティルール、業務ルールは、すべて組織レベルの資産であり、特定のエンジニアの「経験値」ではない。Atos の19,000のエージェントが54カ国で稼働できるのは、ガバナンスが「誰かが理解している」ではなく「システムとして強制されている」からだ。

示唆その3：ゲート（門番）はスピードより重要。

GitHub Spec Kit の5段階ゲート（constitution → specify → plan → tasks → implement）、Claude Code の「テストが失敗するまでコードを書かない」、Kiro の「spec を書かないと起動しない」——これらはすべて同じことをやっている：AI と最終成果物の間に「ブレーキ」を挟むのだ。各ステップには監査可能な成果物（spec.md、plan.md、tasks.md）があり、コード生成前に却下・修正できる。

自律性が高まるほど、ゲートは必須になる。 金融業界の変更諮問委員会（Change Advisory Board, 変更諮問委員会 (CAB)）、アルゴリズム登録（AI 推進法 / AI ガバナンス (総務省/経産省 行政指引)）、ISMS (JIS Q 27001) 適合性評価（中国のサイバーセキュリティ等級保護評価）は、いずれも本質的には本番投入前にゲートを設ける仕組みだ。AI コードにも同様のゲートが必要だが、形は異なる。New Relic の2026年レポートで「自信を持ってレビューなしでリリースする」と答えた62%のチームは、その自信をより高い障害率（78%）で支払っている。

金融業界の規範導入3フェーズ（2026 H1 実践版） フェーズ1：ルール棚卸し 2〜4週間｜最も時間がかかるが、ROI最高 コンプライアンス要件リスト（等保/越境/届出） セキュリティルール（パスワード/暗号化/ログ） 業務ルール（リスク管理/取引/課金） 技術的制約（旧インターフェース/バージョン制限） ベンダーガバナンス（契約/監査/責任） 散在するルールを 構造化ドキュメントに整理 第二段階：リポジトリへ格納 1〜2週間｜リポジトリに格納、AIが自動ロード CLAUDE.md / AGENTS.md constitution.md Skills定義（共有可能なワークフロー） ゲートプロセス設計（5段階） .claude/rules/（階層ルール） ルールをリポジトリに格納し、 AIが自動ロード 第三段階：制度化 継続｜ツールから組織能力へ CIゲート（自動レビュー） チーム共有設定（スキル） 定期更新メカニズム（四半期レビュー） メトリクス（欠陥率/コンプライアンス合格率） エージェントガバナンス（Agent 365 第一級） 規範が組織資産となり、 個人に依存しない

第一段階が最も時間がかかるが、ROIは最高
多くの金融組織のルールは文書/メール/頭脳に散在しており、初回整理は3〜8週間の投資

四、2026年上半期における実践的な3段階アプローチ

金融業界を例にした3段階の進め方です。他の強規制業界でも参考にできます。EYとAtosが2026年上半期に実践した内容が、ちょうどこの3段階に対応しています。

第1段階：ルールの棚卸し（2〜4週間）

最も時間がかかりますが、ROIが最も高い段階です。各所に散らばったルールを洗い出します：

  • コンプライアンス要件：金融業界の最低基準 = 等保三級（中国の情報セキュリティ等級保護制度における第三等級）+ データ出境評価（越境データ移転の安全性評価）+ アルゴリズム备案（アルゴリズム届出制度）（この3つが揃わなければAI展開は不可）。さらに規制当局への報告ルール、顧客情報保護、越境データ移転の制限、AIに参照させてよいデータの範囲などがあります
  • セキュリティルール：パスワード管理、暗号化基準、機密フィールドの取り扱い、ログ要件
  • ビジネスルール：リスク管理のしきい値、保険金支払い条件、取引制限、課金ロジック
  • 技術的制約：レガシーシステムのインターフェース、データベース命名規則、フレームワークのバージョン制限
  • ベンダーガバナンス：契約上でベンダーに当社の規準を順守させる方法、ベンダーのAI利用を監査する方法

典型的なケースとして、某証券会社は棚卸しの段階で、ルールが大量のWord文書、JIRA wiki、個人のメール、Excelシートに散在していることに気づき、整理して初めて構造化されたルールリストを得た。Atosのやり方はより体系的だ。彼らはルールを「コンプライアンス、セキュリティ、ビジネス、テクノロジー、ベンダー」の5つのカテゴリに分け、各カテゴリに1つのガバナンスワークフローを設け、Agent 365のコントロールプレーンに統一的に接続した。

これは技術的な作業ではなく、組織的な取り組みだ。コンプライアンス部門、セキュリティ部門、ビジネス部門を一堂に集め、全員が合意するルールを文書化する必要がある。初回の実施では、金融機関は通常3〜8週間かかるが、これは恒久的な組織資産となる。

第2段階：リポジトリへの格納（1〜2週間）。

第1段階で整理したルールをドキュメントにまとめ、リポジトリに格納する。GitHub Spec Kitはconstitution.md、Claude CodeはCLAUDE.md、OpenAI CodexはAGENTS.md、Alibaba QoderはSpec Workflowを使用する。ファイル名は異なるが、目的は同じ——AIがリポジトリを開いた瞬間に読み込まれることだ。

構成提案（2026年上半期の主流形態）：

  • プロジェクト概要：このシステムが何をするのか、誰にサービスを提供するのか
  • 譲れない原則：セキュリティ上のレッドライン、コンプライアンス上のレッドライン、ビジネス上のレッドライン
  • 技術スタックと制約：どのフレームワーク、どのデータベース、どのAPI仕様を使用するか
  • コーディング規約：命名規則、ディレクトリ構造、テストの最低カバレッジ要件（TDDのリズムは強制しない——テストカバレッジ率、必須テストパス、禁止パスを明確に記載すればよい。TDDは組織の任意の進め方であり、規約で強制するものではない）
  • ビジネスルール：リスク管理ロジック、取引ルール、課金ルール
  • コンプライアンス要件：等保（サイバーセキュリティ等級保護）、データ越境移転、監督当局への報告、AI生成アルゴリズムの届出が必要かどうか
  • AI利用規範：どのような場面でAIを使用できるか、どのような場面で必ず人間によるレビューが必要か、データ越境に関するルール
  • ベンダーガバナンス：契約条項、監査メカニズム、責任分担

付録：CLAUDE.md 金融版スケルトン（約200行、そのままフォークしてカスタマイズ可能）

以下は、株式制銀行のコアシステム刷新に向けたCLAUDE.mdのスケルトンです。「譲れない原則 → コンプライアンス要件 → AI利用規範 → ビジネスルール → エンジニアリング制約」の順に構成されています。ゼロから作る必要はありません——空欄に御社の具体的なルールを埋めるだけで使えます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
# CLAUDE.md — <システム名> AI 協働規範

> 適用範囲：<システム名> v<バージョン>、すべての AI 代理（Claude Code / Cursor / Copilot / Codex）
> は本リポジトリで作業する際、本規範を遵守しなければならない。本ファイルは <ガバナンス委員会> が
> 維持し、四半期ごとにレビューする。
> 最終更新：YYYY-MM-DD

## 1. プロジェクト概要
- **業務ポジショニング**：基幹システム名 / サービス対象顧客セグメント / 主要取引タイプ
- **重要プロセス**：取引 → リスク管理 → 決済 → 照合 → 規制報告
- **利用不可時間帯**：<YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM>（いかなる変更も進入禁止）
- **主要依存関係**：上流 <システム>、下流 <システム>、規制報告プラットフォーム

## 2. 交渉不可の原則（レッドライン、違反時はマージを拒否）

### 2.1 セキュリティ レッドライン
- パスワード、鍵、Token はすべて KMS（鍵管理サービス）経由とする。**ハードコード禁止**、**ログ出力禁止**
- 顧客の機微フィールド（身分証 / カード番号 / CVV / 電話番号）は**必ず暗号化保存**し、平文での DB 格納を禁止
- ログに以下を含めてはならない：完全な身分証番号、完全なカード番号、平文パスワード、顧客氏名＋電話番号の組み合わせ
- 外部 API 呼び出しは必ず API ゲートウェイを経由し、直接接続を禁止

### 2.2 コンプライアンス レッドライン
- AI 生成コードが顧客データアクセスを含む場合、PR 説明欄に「データアクセス：<フィールド>」と必ず記載
- クロスボーダー データ転送は禁止、**すべてのデータ越境はデータ越境評価（データ出境评估）プロセスを経る**（コンプライアンス部門に連絡）
- アルゴリズム判断（与信 / 保険定价 / 不正検知）は必ず人間によるレビュー導線を残す
- モデル変更はアルゴリズム登録（AI 推進法 / AI ガバナンス (総務省/経産省 行政指引)）を経る必要があり、登録番号を PR 説明欄に必ず引用

### 2.3 ビジネス レッドライン
- リスク管理しきい値の変更にはリスク管理責任者 + 業務責任者の二名承認が必要
- 顧客資金を扱う操作には必ず冪等性設計 + 失敗時のロールバックを実装
- 取引限度額、手数料率、プロダクト パラメータの変更はパラメータ管理プラットフォーム経由とし、コードにハードコードしない

## 3. 技術スタックと制約
- **言語**：Java 17（コア）/ Kotlin（新規モジュール）/ SQL（データベース）
- **フレームワーク**：Spring Boot 3.x + Spring Cloud Alibaba
- **データベース**：OceanBase 4.x（MySQL 互換モード）、**外部キーの使用禁止**
- **インターフェース仕様**：内部は一律 gRPC；外部インターフェースは OpenAPI 3.0；RESTful は管理系インターフェースのみ
- **命名規約**：Java クラスは PascalCase、メソッドは camelCase、定数は UPPER_SNAKE；テーブル名 `t_<業務ドメイン>_<エンティティ>`；インデックス `idx_<テーブル>_<フィールド>_<順序>`
- **パッケージ構造**：`com.<会社>.<業務ドメイン>.<サブドメイン>.<層>`（例：`com.bank.pay.tx.core.service`）

## 4. コード規範
- **テスト最低カバレッジ**：コア系 ≥ 80%、ユーティリティ ≥ 60%、新規コードの PR には必ずテストを含める
- **必須テスト経路**：すべての controller には統合テスト（含：失敗経路）が必要；すべての enum 分岐には単体テストが必要
- **禁区経路**：`<歴史的負債モジュール>` ディレクトリの変更を禁止——先にアダプタ層を構築すること
- **依存関係管理**：新規サードパーティ依存は SCA スキャン + セキュリティ承認を経る

## 5. 業務ルール（ドメイン別）
### 5.1 取引
- 一回限度額：<金額>；一日限度額：<金額>；超過時は手動承認
- 取引時間帯：<HH:MM> ~ <HH:MM>
- 重複取引判定：<時間枠> 内に同じ <フィールド> の取引を重複とみなす

### 5.2 リスク管理
- ブラックリスト照合優先順位：内部ブラックリスト → 規制配布リスト → 司法凍結
- 不正検知モデル出力しきい値：<分数>；超過時は必ず人間の二次レビュー

### 5.3 課金
- 手数料率変更には必ずバージョン番号 + 発効日を設定
- 過去の注文は発効時の手数料率で計算し、遡及しない

## 6. コンプライアンス要件
- 等保三级（MLPS レベル3）：<評価機関>、<次回評価日>
- データ越境評価（データ出境评估）：適用範囲（クロスボーダー業務モジュールのみ）
- アルゴリズム登録（AI 推進法 / AI ガバナンス (総務省/経産省 行政指引)）：適用範囲（与信 / 保険定价等の重要アルゴリズム）、登録番号 `<番号>`
- 規制報告（监管报送）：<銀保监 / 人行（銀行保険監督管理委員会 / 中央銀行）> フィールド マッピング表は `<パス>`

## 7. AI 利用規範
- **AI 利用可能シーン**：CRUD テンプレート、単体テスト生成、ドキュメント初稿、SQL 最適化提案
- **必ず人間レビューが必要なシーン**：リスク管理ロジック、課金ルール、権限制御、暗号化 / 復号、クロスボーダー データ
- **AI 単独実行禁止シーン**：変更諮問委員会 (CAB)（変更諮問委員会）承認資料、本番変更実行、緊急時対応
- **データ越境ルール**：学習データ / プロンプト / 出力ログはすべて越境禁止；ローカル展開版（<ベンダー>）を優先
- **監査要件**：すべての AI 生成コードは PR 説明欄に「AI 補助：<ツール名>」と必ず記載

## 8. ベンダー ガバナンス
- **ベンダー参入審査**：SOC 2 / ISO 27001 レポートの提出が必要；AI モデルはモデル カードの提出が必要
- **契約条項**：データ帰属、モデル解釈性、脱退条項、監査権
- **監査メカニズム**：四半期ごとのベンダー AI 利用監査；高リスク ベンダーは月次監査

## 9. ガバナンスと更新
- **所有者**：<ガバナンス委員会>（コンプライアンス + セキュリティ + アーキテクチャ + 業務）
- **更新頻度**：四半期レビュー；緊急変更は快速通路（二名承認 + 24 時間公開）
- **変更ログ**：`CLAUDE_CHANGELOG.md` を参照
- **違反処理**：初回違反 = 警告 + 強制研修；二回目 = AI ツール利用停止；三回目 = 権限取消

この骨格は「正解」ではなく「穴埋めテンプレート」だ。各スロットに何を入れるかが、分量よりも重要である——空白部分にこそ、自社が「まだ考え切れていない」領域が浮き彫りになる。

典型的な例として、某株式銀行のCLAUDE.mdではパスワード処理ルールが明文化されており、AIが生成したコードでパスワードを扱う場合、内部の鍵管理APIを呼び出すことが必須で、ハードコーディングは禁止されている。こうしたルールは、コンプライアンス審査で差し戻しになる理由の上位を占めている。

2026年上半期の重要な新フィールドは Skills／ワークフロー定義 だ——単なるドキュメントではなく、AIが呼び出せるツールチェーンである。Claude CodeのSkillsシステム（2026年2月にAnthropic公式マーケットプレイスへ登場、GitHubスター11.2万）により、「Excelの読み取り」「SQL生成」「データ移行の実行」といった工程が共有可能なワークフローになる。これこそが規範主導の2026年上半期における重要な進化だ：規範は単なる制約ではなく、実行可能なワークフローなのである。

第三段階：制度化（継続的）。

規範を書き終えたら終わりではない。むしろ、そこからが始まりだ。それを組織のプロセスに組み込んでこそ意味がある：

  • CIゲート統合：コードが規範に従っているかを自動チェックする（例：パスワードのハードコーディング検出、機密フィールドの未暗号化検出）
  • チーム共有設定：Skillsシステムを使い、チーム全体で同じ規範を共有する
  • 定期的な更新メカニズム：ルールが変われば規範も変える（四半期レビュー）
  • 測定とフィードバック：AIコードの欠陥率、コンプライアンス審査通過率、手戻り率を追跡する
  • エージェントガバナンス：人に対するガバナンスをAIエージェントにも拡張する——AtosがAgent 365でやっているのは、これを「個人レベル」ではなく「システムレベル」にしたことだ

EYとAtosは2026年上半期、いずれも第三段階を「組織能力」として位置づけている。EYの250万時間の削減は、第一段階と第三段階を正しく実行した成果だ——第二段階は単にルールをAIが読めるドキュメントに翻訳したに過ぎない。

五、強規制バリアント：コンプライアンスを組み込む3つの工学的アプローチ

金融、通信、医療といった強規制業界では、規範駆動の導入は一般業界よりもハードルが一つ多い——コンプライアンスはプロセスの付属物ではなく、コードに組み込まれるものだ。以下に示す3つのアプローチは、2026年上半期に実証されたコンプライアンス組み込み方法であり、CIOやデジタル責任者が組織設計を行う際にそのまま参考にできる。

5.1 ストリームチームへのコンプライアンス担当者組み込み：承認ではなく「その場に存在する」コンプライアンスへ

従来の進め方では、ビジネスチームがコードを書き、コンプライアンスチームが事後的にレビューする——というのが一般的だ。しかしこの場合、レビューで問題が発覚した頃にはコードはすでに2週間前に本番稼働しており、手戻りに2〜4週間かかる。問題の本質は、コンプライアンスがプロセスの末端に置かれていることにある。

新しいアプローチは、各ストリームアラインドチーム（stream-aligned team）にコンプライアンス担当者を常駐させるというものだ。形式上は「実線がコンプライアンス部門、点線がビジネスチーム」というデュアルレポート構造をとる。具体的な設計は以下の通り：

  • 人員配置：コンプライアンス担当者はストリームチーム6〜8つにつき1名を配置。所属はコンプライアンス部門だが、物理的な席はビジネスチーム内に置く——出張ベースの「一時派遣」ではない
  • 点線側のKPI：コンプライアンス担当者の評価ウェイトの50%は、ビジネスチームの「コンプライアンス欠陥率」と「レビュー一発合格率」に連動させる。コンプライアンス部門内の「監査カバレッジ」だけを見るのではない
  • 事前介入：コンプライアンス担当者はデイリースタンドアップ（週1回で十分）、PRレビューに参加する。AIが生成したコードは、マージ前に必ずコンプライアンス担当者の確認を通す——マージ後に発覚してから後追いで対応するのではなく
  • ツールによる支援：コンプライアンス担当者は、コンプライアンスチェックリストをSkillsとして呼び出して活用する。人手による項目ごとの照合はしない

典型的なシナリオ：某全国規模の株式制銀行が2026年上半期に3つのストリームチームへコンプライアンス担当者を組み込み、AIコードのコンプライアンス差し戻し率を35%から8%に引き下げた——その核心は、コンプライアンスが「より厳しく見る」ことではなく、「より早く見る」ことにある。この取り組みの成否を分けるのは、コンプライアンス担当者の間接的なインセンティブ設計がビジネス目標と整合しているかどうかだ——もし担当者のKPIが依然としてコンプライアンス部門から与えられたタスクだけを基準にしているなら、その組み込みは失敗に終わる。

5.2 コンプライアンスをenabling team化する：制約をaffordanceに変える

従来のやり方では、コンプライアンスチームは「ゲートキーパー」であり、ビジネスチームからは「面倒の元」と見なされていた。両者はゼロサムゲームの関係にあった。

新しいアプローチ：コンプライアンスチームをTeam Topologiesのenabling teamパターンに再編成する——直接コードを書いたりPRをレビューしたりはしないが、ビジネスチームが「セルフコンプライアンス」を実現できるように、次の3つを提供する：

5.3 デュアルスピード・コンプライアンス：ビジネスのテンポに合わせた階層的適用

  1. CIパイプライン内でのコンプライアンスチェック：パスワードのハードコーディング、機密フィールドの平文保存、クロスボーダーデータ転送、アルゴリズム上の意思決定ポイントといった高頻度のコンプライアンス項目を、GitHub Actions / GitLab CI 上の強制ゲートとして組み込む。開発チームのPRは自動チェックがトリガーされ、不適合があれば即座にfail——コンプライアンス担当者が手動でレビューを回す必要はない
  2. 規制要件をaffordance（環境によるレスポンシブな制約）として設計する：例えば、顧客データを扱う機能を開発する際、IDEプラグインが「このフィールドはKMSの呼び出しを推奨します」というヒントを表示する。ログ出力時には、機密情報が含まれていないかを自動検出してアラートを出す。コンプライアンス要件を「開発時に自然発生するアクション」にするのであって、「リリース直前に何に違反したかを知らされる」のではない
  3. 共有Skillsライブラリ＋コンプライアンス研修：コンプライアンスチームが「コンプライアンスSkills」セットを維持し、新人入社時やチーム間異動時に直接呼び出せるようにする——コンプライアンス知識を「ドキュメント」から「実行可能なツール」へ変換する

典型的なシナリオ：某都市商業銀行は2026年上半期にCIコンプライアンスゲートとIDEコンプライアンスヒントを導入し、AIコードレビューの担当者あたり所要時間を45分/回から8分/回に短縮した。重要なのはコンプライアンス「レビューが速くなった」ことではなく、AIがコードを生成する時点で「そもそも違反しない」ことにある。

最後に、コンプライアンスは「一律適用」ではうまくいきません。ルールをリスクレベルに応じて2段階に分けましょう：

  • 高リスクルール（顧客資金／アルゴリズム判断／越境データ／等保（ISMS (JIS Q 27001) 適合性評価、中国のサイバーセキュリティ等級保護制度）のレッドラインに関わるもの）は厳格なゲートを適用：必ず人間によるレビュー＋AIによる二次確認＋変更諮問委員会 (CAB)（Change Advisory Board）への登録が必要
  • 低リスクルール（CRUDの雛形／ツール系コード／ドキュメント生成）はセルフサービスゲートで対応：CIの自動チェックのみでよく、人間のレビューは不要

AtosのAgent 365コントロールプレーンも、本質的にはこの階層構造です——エージェントのレベルに応じて、異なるガバナンス要件をバインドしています。コンプライアンスルールをリスクで階層化することで、ビジネスチームは「コンプライアンスがどこでも邪魔してくる」と感じずに済みます。

この3つを合わせて考えると：コンプライアンスの埋め込みは「プロセスを1つ追加する」ことではなく、チームの構造とインセンティブを再設計することです。もしコンプライアンス部門がまだ「事後レビュー」モードのままだと、規範駆動の導入は最も難しい「制度化」の段階でつまずきます——コンプライアンス部門が先に変革しない限り、ビジネスチームの規範駆動はスムーズに回りません。

六、気になる質問

「すでにコーディング規約があるけど、それと何が違うの？」

コーディング規約が扱うのは「コードの書き方」、規範駆動が扱うのは「AIとの協働の仕方」です。コーディング規約には含まれないもの：ビジネスルール、コンプライアンス要件、AI利用ポリシー。規範駆動は「人とAIが協働する全プロセス」を明示化するものであり、コードスタイルガイドではありません。

「規範を書いたら開発スピードが落ちるのでは？」

短期的には落ちます。長期的には落ちません。CodeRabbit のデータが明確に示しています。制約なしの AI コードは欠陥リスクが約1.7倍、セキュリティ脆弱性が2.74倍です。金融業界では、コンプライアンス審査による手戻り1回で2〜4週間かかります——手戻りを1回防げれば、1ヶ月分の規範を書く時間など軽く賄えます。EY が2.5億ドルを削減できたのは、これを組織能力として定着させた証拠です。

「うちのチームに規範を書ける人材がいないのですが？」

ゼロから書く必要はありません。GitHub Spec Kit、Claude Code Superpowers、AWS Kiro にはテンプレートが用意されています。組織固有のルールを埋め込むだけで済みます。その大半はコンプライアンスとセキュリティのルールで、コンプライアンス部門やセキュリティ部門がすでに文書化済みのはずです。ただ、それが AI から参照できる場所に置かれていないだけです。

「AI ツールが多すぎて、どれを選べばいいのか分かりません。」

重要ではありません。すでに使っているものを選んでください。規範ドリブンであってツール非依存——CLAUDE.md は Claude Code・Cursor・Codex のいずれでも機能します。AGENTS.md は OpenAI エコシステムで動作します。constitution.md はモデルに依存しません。肝心なのは規範を書くことであって、ツールを乗り換えることではありません。EY も Atos も Microsoft エコシステム上で展開しています。ツールの選択が異なって見えるのは表面的な話にすぎず、ガバナンス構造の統一こそが本質です。

「2026年8月にEU AI Actが全面適用されますが、これは我々に影響がありますか？」

はい、あります。EU AI Act（欧州AI規則）は2026年8月2日に全面適用段階に入り、高リスクAIシステム（信用貸付、保険料率設定、採用選考、重要インフラを含む）に対して強制コンプライアンス要件を課しています——リスク管理（第9条）、データガバナンス（第10条）、文書化と透明性（第11〜13条）、人間による監督（第14条）、正確性・堅牢性（第15条）です。違反時の罰金は最大3,500万ユーロまたは全世界売上高の7%に上ります。中国から海外展開する企業にとって、EU市場は避けて通れない課題です。国内企業にとっても、EU AI Actの枠組みはグローバルで最も参照されている基準であり、直接適用されなくても、サプライヤーやパートナー、越境ビジネスを通じた波及影響を無視することは難しいでしょう（whisperly.ai 2026；surecloud.com 2026.6；artificialintelligenceact.eu 2026.6）。

「国内の対応：EUはAIを規制するが、中国は何を規制するのか？」

中国における生成AIのガバナンスは、「アルゴリズム届出（AI 推進法 / AI ガバナンス (総務省/経産省 行政指引)）＋学習データ審査＋安全評価」の3点セットで進められており、2023年8月に施行された『生成式人工智能服務管理暫行辦法（生成AIサービス管理暫行弁法）』が中核的な規制手段となっています。両者の最大の違いは条文の細かさではなく、立法哲学にあります。

| 側面 | EU AI Act | 中国「生成AIサービス管理弁法」 |
|—|—|—|—|
| 法的位置づけ | 横断的規制（あらゆるAIシステムに適用） | 縦断的規則（生成AIサービスに特化） |
| リスク区分 | 4段階（許容不能／高／限定的／最小） | 2段階（世論・安全に関わるもの／一般商用） |
| 規制のタイミング | 事前（開発段階で届出） | 事後（提供開始後の届出＋アルゴリズム届出） |
| 透明性 | 高（学習データの出典概要・モデルカードの開示を義務化） | 中（コーパスのコンプライアンスは求めるが、出典開示は必須ではない） |
| 罰則の上限 | 全世界売上高の7％または3,500万ユーロ | サービス停止／罰金（通常は違法所得の倍数） |
| 適用範囲 | 全世界売上高の基準を満たすすべての企業 | 中国国内でサービスを提供するすべての主体 |

実務上、中国国内の金融機関におけるAIシステムは通常、三層のルールに同時に拘束される——「生成系AI管理弁法」（基盤層）+「商業銀行インターネット貸付管理弁法」（業務層）+ 等保（サイバーセキュリティ等級保護）+ アルゴリズム届出（コンプライアンス層）である。これはつまり、国内で規範駆動の取り組みを行う際、EU AI Actの枠組みをそのまま持ち込むことはできないということだ。「コーパスコンプライアンス＋アルゴリズム届出＋監督報告」という三本の線を、すべてCLAUDE.mdに書き込む必要がある。

海外展開を目指す企業にとっては、EU AI Actの「リスク管理＋データガバナンス＋文書の透明性＋人間による監督」という四点セットは、中国国内の規制も徐々に歩調を合わせつつある方向性である——2025年に網信办（国家インターネット情報弁公室）が示したいくつかの生成系AI届出へのフィードバックは、すでにEUの粒度を明確に参考にしている。今日、EU AI Act互換の規範を書いておけば、今後3年の国内規制の厳格化トレンドにも、高い確率で適合し続けられる（網信办届出公告 2025-2026；eu-ai-act compliance 2026.6）。

七、意思決定者への示唆

示唆その一：CLAUDE.md／AGENTS.mdという形でプロジェクト規範を一文書にまとめることは、AI時代においてROIが最も高いエンジニアリング施策である。

示唆2：規範主導は組織能力の問題であり、ツール選択の問題ではない。

GitHub Spec Kitを選ぶか、Claude Codeを選ぶかは重要ではない。重要なのは、「我々の組織はAIとどう協働するのか」を定義しているかどうかだ。それがなければ、どれだけ優れたツールを使っても、チームがより速いスピードでより多くの技術負債を生み出すだけである。

示唆3：規範を個人の暗黙知に頼らず、組織のプロセスに組み込む。

規範がベテランエンジニアの頭の中にしか存在しないのであれば、人が入れ替わった瞬間に失われてしまう。リポジトリのドキュメント、CIゲート、チーム共有設定、エージェントガバナンスプラットフォームに落とし込む必要がある。規範を個人のスキルではなく、組織の資産にするのだ。Atosの19,000のエージェントが54カ国で稼働できているのは、ガバナンスが「誰かが理解している」ではなく「システムとして強制されている」からだ。

示唆4：スピードよりもゲート（品質管理）を重視する。

GitHub Spec Kit の5段階ゲート、Superpowers の「テストが失敗するまでコードを書くな」、Kiro の「spec を書かなければ起動しない」——いずれも、AI と最終成果物のあいだに“ブレーキ”をかける仕組みだ。AI の能力が高まれば高まるほど、ガバナンスを先に設計しておく必要がある。New Relic の2026年レポートが示す78%という事故率は、62%のチームが「レビューなしでリリースしている」ことの代償である。金融業界のCIOはこの感覚を誰よりも理解しているはずだ。変更審査委員会（Change Advisory Board, 変更諮問委員会 (CAB)）、アルゴリズム届出、ISMS (JIS Q 27001) 適合性評価（中国のサイバーセキュリティ等級保護評価）——これらはすべて、本番適用の前にゲートを設ける仕組みだ。AI が生成するコードにも、同じようなゲートが必要であり、しかもより前段階に置かなければならない。

逆方向からの自己点検（ここは美化しないこと）：あなたの組織で AI が生成したコードは、コンプライアンス審査で何度も差し戻しになっていないか？直近で AI コードが原因となった問題は何か？技術責任者に「私たちは AI とどう協働しているのか」と聞いたとき、彼はドキュメントを1枚提示できるか？この3つのうち1つでも答えに窮するなら、規範駆動の開発はまだ現場に根づいていない——先に規範を書き、そのあとでツールを導入せよ。

意思決定者のための3つのコーチング質問

最後に3つの質問を残す。チェックリストではない。あなたがチームと議論するときに、そのまま使える問いだ。

  1. 「もし明日、すべてのAIツールが使えなくなったら、あなたのチームのコード品質はどの程度低下しますか？」 —— この問いが浮き彫りにするのは、規範駆動の真の価値です。もし答えが「大幅に低下する」なら、あなたの規範はまだチームに浸透していない証拠。逆に「ほぼ変わらない」と答えられるなら、規範駆動はすでに機能しています。
  2. 「コンプライアンス部門は、あなたの規範駆動プロジェクトにおいて『門番』ですか、それとも『イネーブラー』ですか？」 —— 答えが「門番」なら、承認プロセスがボトルネックとなり、実行スピードが落ちるでしょう。「イネーブラー」と答えられるなら、あなたはすでにセクション5.2で述べた正しい道筋を歩んでいます。
  3. 「12〜18ヶ月後、あなたのチーム規模はどう変わっていますか？」 —— マイクロソフトのWTI 2026レポートによると、リーダーの82%がAIエージェントを使って労働力を「拡張」すると回答しています。もしあなたの答えが「変わらない」なら、ビジネスが成長していないか、組織設計が規範駆動の恩恵に追いついていないかのどちらかです。

これらの問いに絶対的な正解はありません。しかし、答えの「方向性」こそが、答えそのものよりも重要なのです。

次のステップ

本稿は「AI時代のソフトウェアエンジニアリング変革」シリーズの第6回目です。コンウェイの法則（組織がアーキテクチャを決定する）から始まり、Team Topologies（組織をどう設計するか）、ボトルネックの移行（ボトルネックはコーディングではなく検証にある）、そして今回は規範駆動（ドキュメントでAIの振る舞いを制約する）について解説しました。

下一篇（第七篇）では、このすべてを支える基盤インフラ——MCP プロトコル（Model Context Protocol） を取り上げます。Anthropic がオープンソース化したこのプロトコルが、なぜ「AI の USB-C」と呼ばれるのか、OpenAI・Google・Microsoft がなぜすべて追随したのか、そしてマルチツール・マルチエージェントの相互運用をどう可能にするのかを解説します。

この判断フレームワークを自社に導入したいですか？

規範駆動（spec-driven）のアプローチを企業に導入する際、実際に解決すべき課題はたいてい数点に絞られます。中核となるルールをどう CLAUDE.md / AGENTS.md に落とし込むか、既存コードにどう規範を適用するか、コンプライアンス対応をどう組み込むか、そしてパイロット導入の評価指標をどう設定するか——です。

現在、以下の3つの協業形態を提供しています。

  • 企業内研修：貴社の実プロジェクトに即して、規範ドキュメントの整理、CI ゲート設計、コンプライアンス組み込みの導線、ガバナンス体制の構築を支援します。
  • 個別コンサルティング：「自社はまず CLAUDE.md / AGENTS.md を書くべきか」といった明確な意思決定や、既存コードのコンプライアンス改善における優先順位付けに焦点を当てます。
  • 経営層向けセッション・業界講演：AI コーディングツール、規範駆動開発、組織ガバナンス、そして Frontier Firms の動向について取り上げます。

本稿は汎用的なフレームワークを提供するものであり、実際の導入にあたっては、各社のコンプライアンス要件・規制上の制約・エンジニアリング成熟度・既存のデリバリープロセスを踏まえた再設計が必要となる。連携のご相談は coach@iaiuse.com まで。

関連記事：『見招牌方法論 v1.0』（ゆっくり学ぶAI 187）では、企業のAI変革を進める7ステップのフレームワークを体系的に紹介している。

本シリーズについて

「AI時代のソフトウェアエンジニアリング変革」は、通信・金融・製造・ECなどの業界におけるCIO・CDO・CTO・デジタル化責任者を対象とした研究シリーズであり、全18篇にわたって、AIプログラミングツール、規範駆動、組織ガバナンスがソフトウェアデリバリープロセス・組織構造・エンジニアリング成熟度にどのような影響を与えるかを考察する。

本シリーズでは、学術論文・ベンダー資料・業界レポートを継続的に追跡し、研究資料データベースは累計200件以上にのぼる。主要な判断にはエビデンスレベルを明記し、検証済みの事実・ベンダー主張・業界観測・筆者の推論を可能な限り区別している。

筆者は、大企業向けコンサルティングとビジネス分析において約8年の経験を持ち、IBM在籍時には通信・金融・保険・製造業関連のプロジェクトに参画してきた。その後も、通信事業者向けプロダクト、インターネットプロダクト、AIアプリケーション開発の現場で、要件分析・プロダクト設計・クロスチームでの導入推進に携わってきた。

本シリーズにおける規範駆動・組織ガバナンス・エンジニアリングに関する判断は、これらの実践に基づき、公開研究や業界事例と照合しながらクロス検証したものである。具体的なプロジェクト内容についてはすべて匿名化済みであり、一部の業界シナリオは典型的な問題の推論に基づくもので、根拠は文末の参考情報を参照されたい。

このアカウントの背後には実は小規模なチームがいる——私と、長期的に協働している1〜2名の同僚が、それぞれAIプログラミングツールの調査、組織ガバナンス事例の整理、コーチング対話を担当している。文中で「私たちが企業とともに乗り越えた」と述べているプロジェクトの大半は、この数名で共同で納品したものである。クライアントのコンプライアンス上の境界や個人名については引き続き明示せず、匿名性を保つことで、将来の協働メンバーとの関係にも配慮している。

参考情報（すべて検証済み。エビデンスレベルを項目ごとに明記）

  • CodeRabbit (2025.12). State of AI vs Human Code Generation Report. AI が生成したコードの問題数は人間が書いたコードの1.7倍（PRあたり10.83件 vs 6.45件）。論理・正確性で1.75倍、コード品質で1.64倍、セキュリティで1.57倍、パスワード処理で1.88倍、XSSで2.74倍。エビデンスレベル：一次。出典：https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263

  • The Register (2025.12.17). CodeRabbit のレポート全文を報道。470件のオープンソースPRを分析した結果、AI が関与した PR には平均10.83件の問題が含まれ、人間のみによる PR の6.45件を上回った。エビデンスレベル：二次。出典：上記URLと同じ。

  • CodeRabbit / David Loker (2026.1). 「2026年の予測：スピードの罠」——2026年は「コード生成のスピード」から「コード品質とガバナンス」への転換点となる年である。エビデンスレベル：二次。出典：https://tfir.io/ai-code-quality-2026-guardrails

  • New Relic (2026). The 2026 State of AI Coding Report（2026年AIコーディングの現状レポート）。78%のチームがAIコードの本番投入後に障害が増加；62%の技術リーダーが、チームが「自信を持ってレビューなしでAIコードをリリースしている」と認める；96%が可観測性は必須と回答。エビデンスレベル：一次（ベンダーレポート）。出典：https://newrelic.com/resources/report/2026-state-of-ai-coding

  • Microsoft 2026 Work Trend Index Annual Report（2026.5.5）。20,000人のAIワーカーを対象にした調査で、10カ国をカバー。リーダーの82%が、今後12〜18ヶ月以内にAIエージェントを活用して労働力を拡大する計画。81%がAIエージェントの統合は中程度から大規模になると予想。24%がすでにエンタープライズレベルで導入済み。Copilotによる会話の49%が認知業務をサポート。58%のAIユーザーが「1年前にはできなかったこと」を実現しており、この割合はFrontier Professionalsでは80%に上昇。エビデンスレベル：レベル1。出典：https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf

  • Microsoft FY26 振り返り：AI 実験からフロンティア変革へ（2026.7.28）。 EY は Microsoft 365 Copilot を 150,000 人の従業員に展開し、250 万時間・約 2.5 億ドルを節約。さらに 40 万人のグローバル従業員へ拡大し、95% のスピード向上、37% の財務運営コスト削減、最大 90% の手作業ワークフロー削減を達成。Atos は Copilot を 56 か国・56,000 人の従業員と 19,000 の AI エージェントに展開し、ID・セキュリティ・コンプライアンス・ガバナンスを統合するコントロールプレーンを構築。エビデンスレベル：一次（マイクロソフト公式レビュー）。出典：https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Atos Group と Microsoft の戦略的協業（2026.6.9） Atos は、56か国・56,000人の従業員を対象に Microsoft 365 E7（Frontier Suite）を導入し、19,000 の AI エージェントを展開。Entra / Defender / Intune / Purview / Agent 365 の各コントロールプレーンを統合します。エビデンスレベル：一次情報（両社による共同プレスリリース）。出典：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（2025.9 オープンソース化、2026 年上半期に進化）.
    5 段階のゲート方式 /speckit.constitution → /specify → /plan → /tasks → /implement に加え、/clarify /analyze を採用。モデル非依存で、Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code のいずれにも対応。エビデンスレベル：一次。出典：https://github.com/github/spec-kit

  • AWS Kiro（2025.7 リリース、2026 年上半期に進化）.
    3 段階のワークフロー：要件 → 設計 → タスク。spec が定義済みのエージェントアクションをトリガーし、spec を書かなければ起動しない設計。エビデンスレベル：一次。出典：https://kiro.dev/

  • OpenAI Codex + AGENTS.md + Skills（2025-2026年）。Codex 在2026年6月的周活跃用户数突破500万，其中非开发者占比20%；AGENTS.md 与 Skills 构成可组合的指令集。证据等级：一级（OpenAI官方公告）。来源：https://developers.openai.com/codex/skills

  • Claude Code（Anthropic，2026年上半年）。采用 CLAUDE.md + .claude/rules/ + Skills 体系；2026年2月进入 Anthropic 官方市场；Skills 仓库在 GitHub 上获得11.2万 stars；2026年2月 G 轮融资披露年化营收达25亿美元。证据等级：一级。来源：https://code.claude.com/docs/en/claude-directory

  • JetBrains AI Pulse Survey (2026.1). 全世界10,000人以上のプロフェッショナル開発者を対象に、8言語でローカライズして実施。Claude CodeのCSAT（顧客満足度）は91%／NPS 54で業界最高。職場での採用率は18%（9ヶ月で3%から6倍に増加）、北米では24%。Copilotは職場採用率29%ながら成長は頭打ち。Cursorは18%。エビデンスレベル：最上位。出典：https://www.jetbrains.com/lp/tools/ai-tools/

  • Pragmatic Engineer Newsletter (2026.2). 開発者15,000人を対象にした調査。46%がClaude Codeを「最も愛用している」と回答。Cursorは19%、Copilotは9%。エビデンスレベル：最上位。出典：https://newsletter.pragmaticengineer.com/

  • Alibaba Qoder（2025.8 → 2026.7）。 2025年8月にAlibabaが発表。2026年5月15日、Qoder 1.0が「Autonomous Agent Development Workbench」へと進化。Spec-Driven Workflow、Quest Mode、Expert Mode、RepoWikiを搭載。2026年5月28日にはCloud Agents（マネージドエージェントランタイム）をリリース。2026年7月21日にはQoder Securityを発表。2026年5月時点で世界のユーザー数は500万人以上。DingTalk CLIとの統合も実現。2026年5月20日、通義霊馬（Tongyi Lingma）はQoder CNに名称変更。エビデンスレベル：一次。出典：https://www.alibabacloud.com/en/marketplace/qoder；https://baike.baidu.com/en/item/Qoder/1427525

  • vibecoding.app / thebcms.com / tfir.io（2026年上半期） Spec Kit の5段階コマンド、SDDツールの評価比較、EARS表記法。エビデンスレベル：セカンダリ（第三者評価）。出典：https://vibecoding.app/blog/spec-kit-review；https://thebcms.com/blog/spec-driven-development

  • EU AI Act / Code of Practice（2026年8月2日全面施行） 高リスクAIシステムの適合期限は2026年8月2日。既存のGPAIモデルは2027年8月2日まで猶予。罰金は最大3,500万ユーロまたは全世界売上高の7%。Art. 9〜15ではリスク管理、データガバナンス、文書の透明性、人間による監督、正確性・堅牢性を規定。エビデンスレベル：一次（規制＋二次コンプライアンス分析）。出典：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年） 問題の根源の44%はコンテキスト（文脈情報）の欠如に起因。エビデンスレベル：二次（ベンダーレポート）。出典：https://www.qodo.ai/reports/state-of-ai-code-quality/

]]> AIコード問題率1.7倍、セキュリティ脆弱性2.74倍——AIはあなたのルールを見ていない。Spec Kit、Kiro、Codex、Claude Code、Qoderの5プラットフォームが2026年上半期、揃って仕様駆動へ：ルールをCLAUDE.mdとしてリポジトリに置く。 【Spec-Driven】Spec-Driven Development：Scrivere le specifiche è l'azione ingegneristica a più alto ROI nell'era dell'AI — L'evoluzione dell'ingegneria del software nell'era dell'AI — Impara l'AI lentamente 177 https://iaiuse.com/it/posts/spec-driven-development-scrivere-specifiche-e-il-atto-ingegneristico-con-piu-alto-roi-nell-era-ai-trasformazione-dell-ingegneria-del-software-nell-era-ai 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z

Fonti dei dati citati nel testo: CodeRabbit 2025.12 / New Relic 2026 report, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms announcement, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. I casi presentati sono scenari rappresentativi e non fanno riferimento a specifiche aziende.

Il tuo errore più grande non è non aver comprato gli strumenti: è non aver scritto il CLAUDE.md

Il CIO di una banca regionale si è lamentato con me: strumenti di AI acquistati, modelli deployati, personale formato — eppure nell’intero primo semestre 2026 i tempi di consegna non si sono mossi di un giorno. Il responsabile del team core banking è stato ancora più diretto: “Il codice scritto dall’AI funziona, ma ogni volta va riscritto da capo — non conosce le nostre regole interne, non conosce i requisiti normativi, non sa come interfacciarsi con quel sistema legacy di 30 anni.”

Il problema non è che l’AI non sia abbastanza capace — è che non avete scritto le regole. A dicembre 2025, CodeRabbit ha pubblicato un’analisi su 470 pull request open source che è diventata un punto di riferimento citatissimo: le PR collaborative con AI contengono in media 10,83 problemi, contro i 6,45 delle PR puramente umane — 1,7 volte, ovvero il 70% di bug in più. Nel 2026 la storia non è cambiata: New Relic, nel suo 2026 State of AI Coding Report, rileva che il 78% dei team segnala più incidenti dopo aver messo in produzione codice scritto con l’AI, e il 62% dei leader tecnici ammette che i propri team “inviano codice AI con sicurezza, senza rivederlo riga per riga” (New Relic official report 2026, score 0,866, fonte primaria). I due dati dicono la stessa cosa — all’AI non manca capacità, manca contesto.

Ad agosto 2026, ogni narrativa sull’“accelerazione della trasformazione AI” va letta alla luce di questo confronto.

| Schieramento | Progressi (H1 2026) | Controesempi (H1 2026) |
|—|—|—|—|
| EY | Microsoft 365 Copilot distribuito a 150.000 dipendenti, con un risparmio di 2,5 milioni di ore / 250 milioni di dollari; estensione prevista a 400.000 dipendenti globali | Ammette però che il +95% di velocità e il -37% dei costi di operations finanziarie dipendono dalla “standardizzazione preventiva dei processi” |
| Atos | Implementazione in 54 paesi / 56.000 dipendenti; 19.000 agenti AI attivi in parallelo, con un piano di controllo unificato per identità, sicurezza, conformità e governance | Rigore nell’approccio: “prima attiviamo le capacità di governance di Agent 365, poi scaliamo” |
| Microsoft stessa | Work Trend Index 2026: l’82% dei leader prevede di espandere la forza lavoro con agenti AI entro 12-18 mesi | Riconosce nello stesso periodo che “il ritmo del cambiamento organizzativo è in ritardo rispetto all’adozione individuale” — il nodo centrale del concetto di Frontier Firm |

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

Questi due confronti dimostrano una cosa sola: senza governance, scalare significa moltiplicare il rischio per N. La “velocità” di EY/Atos/Microsoft non è una questione di modelli più rapidi, ma di organizzazioni che hanno già risposto alla domanda “come usiamo l’AI”. È questo il contesto in cui la Spec-Driven Development (SDD, sviluppo guidato dalle specifiche) è diventata davvero mainstream nella prima metà del 2026 — non perché gli ingegneri amino la documentazione, ma perché senza specifiche è semplicemente impossibile sopravvivere in un ambiente con 19.000 agenti.

Questo articolo chiarisce tre punti: 1) perché i difetti nel codice generato dall’AI sono oltre 1,7 volte più gravi di quelli umani; 2) come cinque piattaforme — GitHub, AWS, OpenAI, Anthropic e Alibaba — siano arrivate nella prima metà del 2026 allo stesso paradigma: usare la documentazione per vincolare il comportamento dell’AI; 3) perché lo sviluppo guidato dalle specifiche è una capacità organizzativa, non una scelta di strumenti, e quali sono le tre fasi di implementazione nella prima metà del 2026.

Codice AI vs codice umano: distribuzione dei difetti (analisi di 470 PR open source) Report CodeRabbit 2025.12 ｜ tutti i numeri sono rapporti AI / umano (baseline 1.0)

Lunghezza barra = multiplo dei difetti AI rispetto all’umano; baseline 1.0× = livello umano

Baseline 1.0×

Problemi totali

1.7×
AI 10.83 vs umano 6.45 / PR

Errori logici / di correttezza

1.75×

Qualità del codice / manutenibilità

1.64×

Riscontri di sicurezza (complessivo)

1.57×

Gestione errata delle password

1.88×

Vulnerabilità XSS

2.74×
↑ massimo

Codice AI senza vincoli normativi supera l’umano in ogni dimensione
Finanza/telecom = riconciliazione conformità, gestione password, crittografia campi sensibili: l’AI non li vede

Uno: il tasso di difetti dell’AI non è un problema di modello, è un problema di contesto

Nel report di CodeRabbit c’è una frase che viene citata di continuo: “L’AI non ha la logica di business locale: il modello inferisce i pattern del codice per via statistica, non per comprensione semantica. Senza vincoli rigorosi, perde le regole di sistema che gli ingegneri senior hanno interiorizzato.”

Questa frase spiega perché la piattaforma di programmazione AI di CodeRabbit (un’azienda specializzata in code review con AI) abbia visto questi dati prima di altri — ogni giorno analizzano migliaia di pull request e osservano com’è fatto il codice scritto dall’AI. Il dato “più critico” non è il totale, ma la distribuzione:

  • Logica/correttezza +75%: errori di logica di business, errori di dipendenza, errori di flusso di controllo, errori di configurazione — problemi che non emergono necessariamente nei test, ma che in produzione causano incidenti.
  • Qualità del codice +64%: naming incoerente, struttura poco chiara, violazione dei pattern di progetto — è la “categoria con la maggiore differenza”. Un ingegnere senior lo nota al primo sguardo: “questo non è il nostro stile”.
  • Sicurezza +57% (XSS la più alta, 2,74×): gestione impropria delle password (1,88×), riferimenti a oggetti non sicuri (1,91×), esposizione di informazioni sensibili, deserializzazione non sicura (1,82×) — nel settore finanziario, non è una questione di “se funziona”, ma di “se si può rilasciare”.

Il problema non è che l’AI non sia abbastanza potente. È che non vede.

Torniamo al vero punto critico del CIO: tre guasti concreti dell’AI nei sistemi core finanziari.

Primo: l’AI non vede 30 anni di logica di riconciliazione. Le regole di risk management delle banche sono scritte nelle stored procedure del sistema core — scritte 30 anni fa, nessuno le ricorda più per intero. Il codice generato dall’AI sembra logicamente corretto, ma in produzione innesca quel controllo di riconciliazione che nessuno ricorda, facendo fallire l’intero batch di transazioni.

Secondo: l’AI non vede i vincoli di compliance. Le password devono passare dal key management system, i campi sensibili devono essere cifrati a riposo, i log non possono stampare informazioni sui clienti — sono vincoli normativi rigidi, scritti nelle policy interne. L’AI non lo sa: il codice che genera funziona, ma non supera la revisione di conformità.

Terzo: l’AI non vede il tuo debito tecnico. Quel sistema host di 30 anni fa usa un protocollo di interfaccia proprietario, la cui documentazione è andata persa da tempo. L’AI scrive codice secondo lo standard RESTful generico, va in produzione e scopre che le interfacce non combaciano — due settimane di rilavorazione.

Torniamo all’altro dato di New Relic: il 62% dei team “rilascia con sicurezza codice AI senza revisione”, e il 78% segnala più incidenti dopo il deploy. Mettendo insieme questi due numeri, il messaggio è chiaro — il tasso di difetti del codice AI non è il problema; “non sapere quali difetti ha il codice AI” è il problema.

Scenario tipico: una banca commerciale ha introdotto lo sviluppo assistito da AI per il modulo di controllo del rischio del suo sistema core. In tre mesi, il tasso di respingimento delle revisioni di conformità è aumentato in modo significativo. I problemi principali riguardavano la gestione delle password, la crittografia dei campi sensibili e la conformità dei log — tutte regole interne. Queste regole erano scritte nella documentazione interna, ma l’AI non poteva vederle. In seguito, il team ha trasferito le regole chiave in un file CLAUDE.md e il tasso di respingimento è calato nettamente.

2. I cinque grandi player nel primo semestre 2026: tutti sulla stessa strada, quella del “model-driven”

A luglio 2025 GitHub ha rilasciato Spec Kit; all’inizio del 2026 AWS Kiro, OpenAI Codex e Anthropic Claude Code hanno completato l’offerta; a maggio 2026 Alibaba Qoder ha integrato il “Spec-Driven Workflow” nel proprio posizionamento di prodotto. Nel primo semestre 2026, le cinque piattaforme sono arrivate allo stesso paradigma: usare la documentazione per vincolare il comportamento dell’AI. Non è un’invenzione di una singola azienda, ma la risposta collettiva del settore alla “crisi di qualità del codice AI”.

Percorsi guidati da normative delle cinque piattaforme (2025-2026 H1) GitHub Spec Kit Open Source 2025.9 constitution.md Gating a cinque fasi: constitution → specify → plan → tasks → implement Indipendente dal modello, supporta 8+ agenti Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md Workflow in tre fasi: Requisiti → Design → Task Spec-driven integrato nel workflow IDE Trigger a hook per agenti automatici Hook di conformità/audit preinstallati Senza spec non si avvia OpenAI Codex 2025-2026 AGENTS.md + Sistema Skills Set di istruzioni componibili Configurazione condivisa a livello team 5M+ utenti settimanali (2026.6) 20% non sviluppatori Da programmazione a agente generico Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + Competenze (Marketplace ufficiale 2026.2) + Ecosistema MCP CSAT 91% / NPS 54 $2.5B ARR（2026.2） 112k stelle su GitHub Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Modalità Quest in autonomia + Modalità Expert per team + Contesto RepoWiki 5M+ utenti globali (2026.5) 2026.7.21 Qoder Security CLI DingTalk integrato Paradigma comune: scrivere esplicitamente "come collaboriamo con l'IA" in un documento nel repository Far lavorare persone e agenti IA sulla stessa specifica: è l'essenza del model-driven

Vediamo le ultime mosse di ciascuna piattaforma nel primo semestre 2026:

GitHub Spec Kit: implementazione di riferimento, gate in cinque fasi. Open-sourced a settembre 2025, entro la prima metà del 2026 è già diventato lo standard di riferimento del settore. 5 comandi core + 2 supplementari: /speckit.constitution (principi non negoziabili), /speckit.specify (cosa fare e perché), /speckit.plan (come intervenire), /speckit.tasks (scomposizione in task), /speckit.implement (esecuzione), più /clarify e /analyze. Il punto chiave del design è l’indipendenza dal modello — gli stessi file spec/plan/tasks non sono legati a un agente esecutivo specifico: funzionano con Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf e Qwen Code. Questo lo ha trasformato in un “protocollo SDD a livello organizzativo”, non in un prodotto esclusivo di GitHub (vibecoding.app review, giugno 2026, punteggio 0.816, fonte secondaria).

AWS Kiro: la specifica come motore dell’IDE. Pubblicato a luglio 2025, evoluto in un vero e proprio Agent IDE nel primo semestre 2026. Il flusso di lavoro si articola in tre fasi: requisiti → design → task. La differenza rispetto a Spec Kit sta nei “ganci” (hook): i file spec di Kiro possono attivare azioni predefinite dell’agente, incorporando direttamente nel workflow passaggi che richiedono sistemi esterni, come conformità, audit o deployment. Se vuoi obbligare il team a scrivere le specifiche, scegli Kiro — perché senza spec, Kiro non parte (AWS Kiro, luglio 2025; documentazione Kiro.dev, 2026).

OpenAI Codex: AGENTS.md + Skills componibili. Tra il 2025 e il 2026, AGENTS.md è diventato il fulcro dell’ecosistema. Le Skills sono l’estensione chiave del primo semestre 2026: permettono di pre-assemblare procedure come “leggere un file Excel”, “generare SQL” o “eseguire una migrazione dati”, e di richiamarle come mattoncini Lego. A giugno 2026, Codex ha superato i 5 milioni di utenti attivi settimanali, di cui il 20% non sono sviluppatori — un segnale spesso trascurato: la guida tramite specifiche non riguarda più solo i team di ingegneria, ma tutta l’organizzazione. Product, operations e risk management stanno tutti scrivendo file AGENTS.md (annuncio OpenAI del 2.6.2026; recensione thebcms.com del 2026, punteggio 0.801).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic definisce i documenti di istruzioni di progetto come CLAUDE.md (entrato nel mercato ufficiale a febbraio 2026), .claude/rules/ (regole stratificate per directory) e Skills (workflow condivisibili). Claude Code è lo strumento con il più alto tasso di soddisfazione tra gli sviluppatori nel primo semestre 2026 — il sondaggio JetBrains 2026.1 riporta un CSAT del 91% e un NPS di 54, confermati da due ricerche indipendenti (Pragmatic Engineer 2026.2). È il punteggio più alto nell’attuale panorama degli strumenti di coding AI (uvik.net 2026.5, score 0.956, aggregazione di fonti primarie). Claude Code è passato da zero a 2,5 miliardi di dollari di ricavi annualizzati in 9 mesi (dati del round G di Anthropic, febbraio 2026), con 112.000 stelle su GitHub (repository Skills) — gli sviluppatori hanno votato con i fatti, dimostrando il valore reale di un approccio guidato da regole.

Alibaba Qoder: la spinta normativa nel mercato cinese. Rilasciato nell’agosto 2025 e aggiornato alla versione 1.0 il 15 maggio 2026, è passato ufficialmente da “AI IDE” a “Autonomous Agent Development Workbench”. Il suo Spec-Driven Workflow è stato lanciato insieme a Quest Mode (attività multi-file autonome), Expert Mode (team di esperti in parallelo) e RepoWiki (knowledge graph del repository). Il 28 maggio 2026 sono arrivati i Cloud Agents (runtime di agenti completamente gestito), il 21 luglio Qoder Security (capacità di conformità e sicurezza), e nello stesso mese è uscita la versione Mobile (Android/iOS/HarmonyOS). A maggio 2026, gli utenti globali avevano già superato i 5 milioni, e DingTalk CLI lo ha incluso tra gli ambienti di esecuzione agenti supportati (Yahoo Finance 2025; Alibaba Cloud ufficiale 2026; Baidu Baike 2026.7).

3. Lo sviluppo guidato dalle specifiche è una capacità organizzativa, non una scelta di strumenti

Questo è il punto più importante per chi prende decisioni. La spinta normativa non è una scelta di strumenti, ma la definizione di “come la nostra organizzazione collabora con l’AI”. Che tu scelga GitHub Spec Kit o Claude Code non è ciò che conta: ciò che conta è se hai scritto le norme in un documento, le hai messe in un repository, e hai fatto sì che tutte le persone e l’AI lavorino su quella base.

Senza questo, anche i migliori strumenti non fanno altro che far accumulare al team più debito tecnico, a maggiore velocità.

Paradigma condiviso: tutti — esseri umani e agenti AI — lavorano sullo stesso insieme di norme. I cinque team hanno dettagli implementativi diversi (nomi dei file / numero di fasi / meccanismi di hook), ma l’obiettivo è perfettamente identico.

Perché tutto questo si concentra nella prima metà del 2026? Perché la soglia delle capacità dell’AI è già stata superata — Claude Code come agente autonomo, Codex con agenti multipli in parallelo, Cursor con refactoring multi-file: l’AI non è più uno “strumento di completamento”, è un “collega”. Il documento di onboarding che daresti a un nuovo collega, devi poterlo dare anche all’AI.

Mettendo la questione nel contesto delle implementazioni su larga scala della prima metà del 2026, le evidenze diventano ancora più solide. Nel retrospective FY26 pubblicato da Microsoft a luglio 2026, i casi EY e Atos vengono presentati come modello “Frontier Firm” — non perché i modelli siano nuovi, ma perché entrambe le aziende hanno prima risposto alla domanda “come usare l’AI”:

EY: governance prima di tutto, risultati su scala. Tra il 2024 e il 2025, EY ha distribuito Microsoft 365 Copilot a 150.000 dipendenti, risparmiando 2,5 milioni di ore e circa 250 milioni di dollari. Il presupposto è stato “costruire prima il framework di governance dell’AI”: EY ha creato una toolchain unificata con Power Platform, Copilot Studio, Azure, Foundry e Fabric, mettendo conformità, compliance e audit sulla stessa base. Solo così sono arrivati il +95% di velocizzazione, il -37% dei costi operativi finanziari e fino al -90% dei flussi di lavoro manuali. Il vicepresidente di EY è stato molto diretto all’AI Tour 2026: “Non abbiamo prima distribuito l’AI e poi aggiustato la governance: abbiamo prima costruito la governance e poi distribuito l’AI”.

Atos: un piano di controllo unificato per 19.000 agenti. Atos è tra le prime organizzazioni al mondo ad aver implementato Microsoft 365 E7 (Frontier Suite), distribuendo Copilot a 56.000 dipendenti in 54 paesi. Oggi gestisce simultaneamente 19.000 agenti AI — dall’IT interno ai reparti business fino ai progetti per i clienti, tutti costruiti con Foundry e Copilot Studio. Il fattore chiave del successo di Atos è “un unico piano di controllo”: Entra (identità) + Defender (sicurezza) + Intune (dispositivi) + Purview (conformità) + Agent 365 (governance degli agenti), cinque componenti integrati tra loro. Questo modello di integrazione, tradotto nel settore finanziario, corrisponde a un’architettura di governance — che combina requisiti di cybersecurity, protezione dei dati, conformità normativa, audit e governance dei modelli — piuttosto che a un semplice strumento AI.

Il paradosso del cambiamento organizzativo di Microsoft. Nel report Work Trend Index 2026, Microsoft stessa ammette una cosa: “il ritmo del cambiamento organizzativo è in ritardo rispetto all’adozione individuale”. Tra i 20.000 utilizzatori di AI intervistati, l’82% dei leader prevede di espandere la forza lavoro con agenti AI entro 12-18 mesi, ma solo il 24% ha già completato la distribuzione a livello enterprise. L’81% dei leader prevede che gli agenti AI saranno integrati in modo moderato o significativo nella strategia AI — ma anche in questo caso, solo il 24% lo ha già fatto. Ciò significa che la maggior parte delle aziende si trova a 12-18 mesi di distanza tra “preparazione” e “realizzazione”, e il modo in cui colmare questo divario dipende principalmente dalla governance normativa.

Fonte: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, fonte primaria PDF); analisi Futurum Group 2026.1.26 (fonte secondaria).

Lezione 1: investire nella governance offre un ROI elevato.

CodeRabbit fornisce una base chiara per calcolare il ROI: il tasso di problemi nel codice generato dall’AI è circa 1,7 volte superiore, mentre le vulnerabilità di sicurezza si riducono di 2,74 volte. In pratica, questo significa:

  • Meno rilavorazioni (nel settore finanziario, una sola revisione di conformità può costare da 2 a 4 settimane di lavoro)
  • Meno incidenti di sicurezza (una violazione dei dati comporta multe normative e danni alla reputazione)
  • Costi di manutenzione inferiori (una riduzione del debito tecnico del 40% è un dato ricorrente)

Scrivere un file di specifiche di progetto come CLAUDE.md o AGENTS.md è l’investimento ingegneristico con il ROI più alto nell’era dell’AI. Il caso EY offre una conversione concreta: 150.000 persone che usano Copilot, con un risparmio di 250 milioni di dollari. Da notare: EY non ha risparmiato perché “lo strumento è potente”, ma perché “le specifiche hanno permesso di trasformare il valore dello strumento in risultati reali”.

Secondo insegnamento: incorporare le linee guida nei processi organizzativi, non affidarsi ai singoli individui.

Se le linee guida vivono solo nella testa di un ingegnere senior, si perdono non appena quella persona cambia ruolo o azienda. Vanno consolidate in:

  • Documentazione del repository (AGENTS.md / CLAUDE.md / constitution.md)
  • Controlli CI (verifica automatica della conformità alle linee guida)
  • Configurazione condivisa del team (il sistema Skills rende le linee guida utilizzabili da tutto il team)

Trasformare le regole in patrimonio organizzativo, non in competenza individuale

Questo principio è particolarmente critico nel settore finanziario: i requisiti di conformità, le regole di sicurezza e le policy di business sono asset a livello organizzativo, non la “esperienza” di un singolo ingegnere. I 19.000 agent di Atos operano in 54 paesi proprio perché la governance non è “qualcosa che qualcuno conosce”, ma “qualcosa che il sistema impone”.

Terzo insegnamento: i gate di controllo contano più della velocità.

I gate a cinque fasi di GitHub Spec Kit (constitution → specify → plan → tasks → implement), la regola di Claude Code “non scrivere codice prima che i test falliscano”, e l’impossibilità di avviare Kiro senza uno spec — tutti perseguono lo stesso obiettivo: inserire un “freno” tra l’AI e l’output finale. Ogni fase produce artefatti verificabili (spec.md, plan.md, tasks.md), che possono essere respinti o modificati prima della generazione del codice.

Più l’AI è autonoma, più servono gate di controllo. Il Change Advisory Board (Change Advisory Board (CAB)) nel settore finanziario, le procedure di registrazione degli algoritmi e le valutazioni di conformità (ISO 27001 + ACN 安全指引, il sistema cinese di classificazione della protezione della sicurezza informatica) sono essenzialmente gate introdotti prima della produzione. Anche il codice generato dall’AI richiede gate simili, solo con forme diverse. I team che, secondo il report 2026 di New Relic, rappresentano quel 62% e “pubblicano con sicurezza senza revisione” stanno pagando questa sicurezza con un tasso di incidenti più alto (78%).

Tre fasi di adozione normativa nel settore finanziario (versione operativa H1 2026) Fase 1: Inventario delle regole 2-4 settimane | più impegnativa, ROI più alto Checklist requisiti di conformità (livello di protezione/export/registrazione) Regole di sicurezza (password/crittografia/log) Regole di business (risk control/transazioni/fatturazione) Vincoli tecnici (vecchie API/limiti di versione) Governance fornitori (contratti/audit/responsabilità) Raccogliere le regole sparse Organizzarle in documenti strutturati Fase due: caricamento nel repository 1-2 settimane｜nel repository, l'IA carica automaticamente CLAUDE.md / AGENTS.md constitution.md Definizione Skills (workflow condivisibili) Progettazione flusso di gating (cinque fasi) .claude/rules/ (regole a livelli) Mettere le regole nel repository, l'IA le carica automaticamente Fase tre: istituzionalizzazione Continuo｜da strumento a capacità organizzativa Gating CI (revisione automatica) Configurazione condivisa del team (Skills) Meccanismo di aggiornamento periodico (revisione trimestrale) Metriche (tasso di difetti/tasso di conformità) Governance degli agenti (Agent 365 livello 1) Le normative diventano patrimonio organizzativo, senza dipendere dai singoli

La prima fase richiede più tempo, ma il ROI è il più alto
Nella maggior parte delle istituzioni finanziarie le regole sono sparse in documenti/email/menti; il primo riordino richiede 3-8 settimane

Quattro. Le tre fasi reali di implementazione nella prima metà del 2026

Prendendo il settore finanziario come esempio, il percorso si articola in tre fasi — un modello che può essere esteso ad altri settori fortemente regolamentati. La prassi di EY e Atos nella prima metà del 2026 corrisponde esattamente a queste tre fasi.

Fase 1: Inventario delle regole (2-4 settimane).

È la fase che richiede più tempo ma offre il ROI più alto. Si tratta di rintracciare tutte le regole disperse nell’organizzazione:

  • Requisiti di conformità: nel settore finanziario, la baseline minima = classificazione di protezione di livello 3 (Dengbao, il sistema cinese di classificazione della sicurezza informatica) + valutazione del trasferimento transfrontaliero dei dati (equivalente alle norme GDPR sull’export di dati) + registrazione degli algoritmi (il meccanismo cinese di filing per i sistemi algoritmici) — se manca anche solo uno di questi elementi, niente implementazione di AI. A questo si aggiungono gli obblighi di reporting regolamentare, la protezione dei dati dei clienti, le restrizioni sui flussi di dati transfrontalieri e la definizione di quali dati possono essere esposti ai sistemi di AI
  • Regole di sicurezza: gestione delle password, standard di crittografia, trattamento dei campi sensibili, requisiti di logging
  • Regole di business: soglie di rischio, condizioni di liquidazione sinistri, limiti di transazione, logiche di fatturazione
  • Vincoli tecnici: interfacce dei sistemi legacy, naming convention dei database, limiti di versione dei framework
  • Governance dei fornitori: come imporre contrattualmente ai fornitori l’adozione dei nostri standard, come auditare l’uso dell’AI da parte dei fornitori

Scenario tipico: durante la fase di inventario, una società di brokeraggio scopre che le regole sono sparse in una marea di documenti Word, wiki JIRA, email personali e fogli Excel — solo dopo averle raccolte si ottiene un elenco strutturato di regole. L’approccio di Atos è più sistematico: suddividono direttamente le regole in cinque categorie — “conformità, sicurezza, business, tecnica, fornitori” — ognuna con un workflow di governance dedicato, tutte integrate nel piano di controllo di Agent 365.

Non è una questione tecnica, è una questione organizzativa: devi riunire il team di conformità, il team di sicurezza e il team di business, e mettere per iscritto le regole che tutti condividono. La prima volta che lo fai, un’organizzazione finanziaria impiega in genere 3-8 settimane — ma è un asset organizzativo permanente.

Fase 2: caricare nel repository (1-2 settimane).

Scrivi le regole raccolte nella Fase 1 come documenti e caricale nel repository. GitHub Spec Kit usa constitution.md, Claude Code usa CLAUDE.md, OpenAI Codex usa AGENTS.md, Alibaba Qoder usa Spec Workflow. I nomi dei file sono diversi, ma l’obiettivo è lo stesso: far sì che l’IA le carichi nel momento in cui apre il repository.

Struttura consigliata (forma prevalente nella prima metà del 2026):

  • Panoramica del progetto: cosa fa questo sistema e a chi serve
  • Principi non negoziabili: linee rosse di sicurezza, conformità normativa e continuità operativa
  • Stack tecnologico e vincoli: framework, database e standard di interfaccia adottati
  • Standard di codice: convenzioni di naming, struttura delle directory e requisiti minimi di copertura dei test (senza imporre il ritmo TDD — basta definire soglie di copertura, percorsi obbligatori da testare e percorsi vietati; il TDD resta una scelta organizzativa, non un requisito normativo)
  • Regole di business: logiche di risk management, regole transazionali e criteri di fatturazione
  • Requisiti di conformità: classificazione della sicurezza, trasferimento transfrontaliero dei dati, reporting regolamentare e obbligo di registrazione per algoritmi di IA generativa
  • Linee guida sull’uso dell’IA: casi d’uso ammessi, ambiti che richiedono revisione umana obbligatoria e regole sul trasferimento dei dati all’estero
  • Governance dei fornitori: clausole contrattuali, meccanismi di audit e ripartizione delle responsabilità

Appendice: scheletro CLAUDE.md per il settore finanziario (circa 200 righe, pronto da fork e adattare)

Di seguito uno scheletro di CLAUDE.md pensato per la modernizzazione del core banking di una banca commerciale, organizzato secondo la sequenza “principi non negoziabili → requisiti di conformità → uso dell’IA → regole di business → vincoli ingegneristici”. Non serve partire da zero: basta inserire le vostre regole specifiche negli spazi predisposti.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
# CLAUDE.md — <nome del sistema> — standard di collaborazione con l'AI

> Ambito di applicazione: <nome del sistema> v<versione>. Tutti gli agenti AI (Claude Code / Cursor / Copilot / Codex)
> che lavorano in questo repository devono rispettare il presente standard. Il file è mantenuto dal <comitato di governance>,
> con revisione trimestrale.
> Ultimo aggiornamento: YYYY-MM-DD

## 1. Panoramica del progetto
- **Posizionamento di business**: nome del sistema core / segmenti di clientela / principali tipologie di transazione
- **Catena critica**: transazione → risk management → compensazione → riconciliazione → segnalazione
- **Finestra di indisponibilità**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (vietato qualsiasi intervento)
- **Dipendenze principali**: sistema a monte <sistema>, sistema a valle <sistema>, piattaforma di segnalazione regolamentare

## 2. Principi non negoziabili (linee rosse: ogni violazione = rifiuto della merge)

### 2.1 Linee rosse di sicurezza
- Password, chiavi e token devono passare esclusivamente dal KMS (Key Management Service): **vietato l'hardcoding**, **vietata la stampa nei log**
- I campi sensibili del cliente (documento d'identità / numero di carta / CVV / cellulare) **devono essere cifrati a riposo**; il testo in chiaro non può essere memorizzato in banca dati
- Nei log è vietato inserire: documento d'identità completo, numero di carta completo, password in chiaro, combinazione di nome cliente + numero di cellulare
- Le chiamate verso API esterne devono tassativamente passare dal API gateway; le connessioni dirette sono vietate

### 2.2 Linee rosse di conformità
- Se il codice generato dall'AI accede a dati del cliente, nella descrizione della PR deve essere riportata la dicitura "accesso dati: <campo>"
- È vietato il trasferimento transfrontaliero di dati; **ogni uscita di dati deve seguire il processo di Valutazione del trasferimento transfrontaliero di dati** (contattare l'ufficio conformità)
- Le decisioni algoritmiche (credito / tariffazione assicurativa / antifrode) devono mantenere un canale di revisione umana
- Ogni modifica di modello richiede la Registrazione degli algoritmi; il numero di registrazione deve essere citato nella descrizione della PR

### 2.3 Linee rosse di business
- La modifica delle soglie di risk management richiede la doppia firma del responsabile risk management + responsabile di business
- Le operazioni che coinvolgono fondi del cliente devono prevedere un design idempotente + rollback in caso di fallimento
- Le modifiche di limiti di transazione, commissioni e parametri di prodotto passano dalla piattaforma di gestione parametri; nessun hardcoding nel codice

## 3. Stack tecnologico e vincoli
- **Linguaggi**: Java 17 (core) / Kotlin (nuovi moduli) / SQL (database)
- **Framework**: Spring Boot 3.x + Spring Cloud Alibaba
- **Database**: OceanBase 4.x (modalità compatibile MySQL); **vietato l'uso di chiavi esterne**
- **Standard di interfaccia**: gRPC per tutti i servizi interni; OpenAPI 3.0 per le interfacce esterne; RESTful solo per le interfacce di gestione
- **Convenzioni di denominazione**: classi Java in PascalCase, metodi in camelCase, costanti in UPPER_SNAKE; nomi tabella `t_<dominio>_<entità>`; indici `idx_<tabella>_<colonna>_<ordine>`
- **Struttura dei package**: `com.<società>.<dominio>.<sotto-dominio>.<livello>` (es. `com.bank.pay.tx.core.service`)

## 4. Standard di codice
- **Copertura minima dei test**: catena critica ≥ 80%, classi di utilità ≥ 60%; ogni PR di nuovo codice deve includere i test
- **Percorsi da testare obbligatoriamente**: tutti i controller devono avere test di integrazione (inclusi i percorsi di fallimento); tutti i rami degli enum devono avere unit test
- **Percorsi vietati**: è vietato modificare la directory `<modulo di debito storico>` — occorre prima creare uno strato di adattamento
- **Gestione delle dipendenze**: ogni nuova dipendenza di terze parti richiede una scansione SCA + approvazione della sicurezza

## 5. Regole di business (per dominio)
### 5.1 Transazioni
- Limite per singola operazione: <importo>; limite giornaliero: <importo>; il superamento richiede approvazione manuale
- Finestra temporale delle transazioni: <HH:MM> ~ <HH:MM>
- Criterio di duplicazione: stesso <campo> entro <finestra temporale> = transazione duplicata

### 5.2 Risk management
- Ordine di priorità delle liste nere: lista nera interna → liste regolamentari diffuse dall'autorità → blocco giudiziario
- Soglia di output del modello antifrode: <punteggio>; oltre tale soglia è obbligatoria la doppia revisione umana

### 5.3 Fatturazione
- Ogni modifica di tariffa deve avere un numero di versione + una data di decorrenza
- Gli ordini storici sono calcolati con la tariffa in vigore alla data di decorrenza, senza retroattività

## 6. Requisiti di conformità
- MLPS Livello 3 (classificazione cinese di protezione della sicurezza informatica - 等保三级): <autorità di vigilanza>, <data della prossima valutazione>
- Valutazione del trasferimento transfrontaliero di dati: ambito di applicazione (solo moduli di business transfrontaliero)
- Registrazione degli algoritmi: ambito di applicazione (algoritmi critici come credito / tariffazione assicurativa), numero di registrazione `<n. registrazione>`
- Segnalazioni regolamentari: tabella di mappatura dei campi per <CBIRC / Banca Popolare Cinese> al percorso `<percorso>`

## 7. Standard di utilizzo dell'AI
- **Scenari in cui l'AI è ammessa**: CRUD standard, generazione di unit test, bozze di documentazione, suggerimenti di ottimizzazione SQL
- **Scenari che richiedono obbligatoriamente la revisione umana**: logica di risk management, regole di fatturazione, controllo dei permessi, cifratura/decifratura, dati transfrontalieri
- **Scenari vietati all'AI in autonomia**: materiali di approvazione Change Advisory Board (CAB) (Change Advisory Board), esecuzione di modifiche in produzione, gestione delle emergenze
- **Regole sul trasferimento transfrontaliero dei dati**: dati di addestramento / prompt / log di output non possono uscire dal paese; priorità alle versioni con deployment localizzato (<fornitore>)
- **Requisiti di audit**: tutto il codice generato dall'AI deve riportare nella descrizione della PR la dicitura "Assistenza AI: <nome dello strumento>"

## 8. Governance dei fornitori
- **Onboarding dei fornitori**: obbligo di fornire report SOC 2 / ISO 27001; i modelli AI devono essere accompagnati dalla model card
- **Clausole contrattuali**: titolarità dei dati, interpretabilità del modello, clausola di uscita, diritto di audit
- **Meccanismi di audit**: audit trimestrale sull'uso dell'AI da parte dei fornitori; audit mensile per i fornitori ad alto rischio

## 9. Governance e aggiornamenti
- **Proprietario**: <comitato di governance> (conformità + sicurezza + architettura + business)
- **Frequenza di aggiornamento**: revisione trimestrale; per le Modifica di emergenza si attiva il canale rapido (doppia firma + pubblicazione di 24 ore)
- **Registro delle modifiche**: vedere `CLAUDE_CHANGELOG.md`
- **Gestione delle violazioni**: prima violazione = richiamo + formazione obbligatoria; seconda violazione = sospensione dell'uso degli strumenti AI; terza violazione = revoca dei permessi

Questa struttura non è una “risposta standard”, è un “modello da compilare”. Ciò che conta non è quanto scrivi in ogni campo, ma cosa ci metti dentro — gli spazi vuoti rivelano esattamente le parti su cui la vostra azienda “non ha ancora le idee chiare”.

Scenario tipico: il CLAUDE.md di una banca commerciale definisce regole specifiche per la gestione delle password — quando il codice generato dall’AI coinvolge password, deve obbligatoriamente richiamare l’API interna di gestione dei segreti, vietando l’hardcoding. Questo tipo di regole rappresenta una quota elevata dei motivi di respingimento nelle revisioni di conformità.

Nel primo semestre 2026, un campo nuovo e importante è Skills/definizione dei workflow — non più solo documentazione, ma una toolchain che l’AI può effettivamente invocare. Il sistema Skills di Claude Code (entrato nel marketplace ufficiale di Anthropic a febbraio 2026, 112.000 stelle su GitHub) trasforma operazioni come “leggere un file Excel”, “generare SQL” o “eseguire una migrazione dati” in workflow condivisibili. Questa è l’evoluzione chiave del paradigma normativo nel primo semestre 2026: le regole non sono solo vincoli, sono workflow eseguibili.

Fase tre: istituzionalizzazione (continua).

Scrivere le linee guida non è il traguardo, è il punto di partenza. Devi trasformarle in parte integrante dei processi organizzativi:

  • Gate CI integrato: verifica automatica che il codice rispetti le regole (ad esempio, rilevamento di password hardcoded o campi sensibili non cifrati)
  • Configurazione condivisa per il team: usa il sistema Skills per far sì che tutto il team adotti lo stesso set di regole
  • Meccanismo di aggiornamento periodico: quando le regole cambiano, anche le linee guida devono cambiare (revisione trimestrale)
  • Metriche e feedback: monitora il tasso di difetti nel codice generato da AI, il tasso di superamento delle verifiche di conformità e il tasso di rilavorazione
  • Governance degli agenti: estendi la governance dalle persone agli agenti AI — è esattamente ciò che Atos ha fatto con Agent 365, portando questo concetto da “livello individuale” a “livello sistemico”

Nel primo semestre 2026, sia EY che Atos hanno trasformato la terza fase in “capacità organizzativa”. Il risparmio di 2,5 milioni di ore dichiarato da EY è il risultato di aver impostato correttamente la prima e la terza fase — la seconda fase si è limitata a tradurre le regole in documenti leggibili dall’AI.

Cinque. Variante per settori fortemente regolamentati: tre approcci ingegneristici per incorporare la conformità

Nei settori fortemente regolamentati come finanza, telecomunicazioni e sanità, l’implementazione guidata dalle linee guida richiede un passaggio in più rispetto ai settori generali — la conformità non è un modulo esterno al processo, è parte integrante del codice. I tre approcci seguenti sono modalità di incorporazione della conformità validate nel primo semestre 2026, e i CIO e i responsabili della trasformazione digitale possono farvi direttamente riferimento nella progettazione organizzativa.

5.1 Rappresentanti di conformità integrati nei team di flusso: la conformità “presente sul campo”, non “in fase di approvazione”

L’approccio tradizionale: il team di sviluppo scrive il codice, il team di conformità lo verifica a posteriori — quando l’audit rileva un problema, il codice è già in produzione da due settimane, e il costo del rifacimento è di 2-4 settimane. Il problema di fondo è che la conformità arriva alla fine del processo.

Il nuovo approccio: integrare un rappresentante di conformità in ogni team di flusso (stream-aligned team), con una struttura di doppia linea di riporto: “linea solida” verso il dipartimento di conformità e “linea tratteggiata” verso il team di business. Nel concreto:

  • Dotazione organica: un rappresentante di conformità ogni 6-8 team di flusso, inquadrato nel dipartimento di conformità ma con postazione fisica nel team di business — non un “distacco” temporaneo
  • KPI in linea tratteggiata: il 50% della valutazione del rappresentante di conformità è legato al “tasso di difetti di conformità” e al “tasso di superamento delle revisioni al primo colpo” del team di business, non solo alla “copertura degli audit” del dipartimento di conformità
  • Intervento a monte: il rappresentante di conformità partecipa allo stand-up giornaliero (una volta a settimana è sufficiente), alle revisioni delle pull request, e il codice generato dall’AI deve essere validato dal rappresentante di conformità prima del merge — non scoperto e corretto dopo il merge
  • Supporto strumentale: il rappresentante di conformità utilizza le Skills della checklist di conformità, invece di fare verifiche manuali riga per riga

Scenario tipico: una banca commerciale a livello nazionale ha avviato nel primo semestre 2026 un progetto pilota con 3 team di sviluppo che integrano un referente compliance, riducendo il tasso di rifiuto per conformità del codice AI dal 35% all’8% — il punto non è che la compliance “controlli più severamente”, ma che “intervenga prima”. La chiave di questo approccio è che gli obiettivi del referente compliance siano allineati a quelli di business tramite una linea di riporto debole — se il suo KPI resta legato esclusivamente ai compiti assegnati dal dipartimento compliance, l’integrazione è destinata a fallire.

5.2 La compliance come enabling team: trasformare i vincoli in affordance

L’approccio tradizionale: il team compliance fa da “guardiano”, e i team di business lo percepiscono come “quello che crea problemi”. Risultato: un gioco a somma zero tra le due parti.

Il nuovo approccio: il team compliance viene ristrutturato secondo il modello enabling team di Team Topologies — non scrive codice direttamente, non fa review delle pull request, ma fornisce tre elementi che consentono ai team di business di essere “auto-conformi”:

  1. Controlli di conformità integrati nella pipeline CI: i punti critici ricorrenti — hardcoding di password, campi sensibili in chiaro, trasferimenti transfrontalieri di dati, punti decisionali algoritmici — vengono trasformati in gate obbligatori su GitHub Actions / GitLab CI. Una PR del team business attiva il controllo automatico; se non conforme, fallisce direttamente — senza bisogno che il compliance officer faccia una verifica manuale.
  2. Requisiti normativi come affordance (vincoli reattivi all’ambiente): ad esempio, quando si sviluppa una funzionalità che coinvolge dati dei clienti, il plugin dell’IDE mostra un suggerimento del tipo “per questo campo si consiglia di chiamare KMS”; durante la scrittura dei log, il sistema rileva automaticamente se sono presenti informazioni sensibili e genera un alert. L’obiettivo è che la conformità diventi “un’azione naturale durante lo sviluppo”, non “scoprire a posteriori cosa si è violato prima del rilascio”.
  3. Libreria condivisa di Skills + formazione sulla conformità: il team compliance mantiene una raccolta di “Skills di conformità” a cui si accede direttamente all’onboarding di nuovi assunti o al passaggio tra team — trasformando la conoscenza normativa da “documentazione” a “strumento eseguibile”.

Scenario tipico: una banca regionale cinese ha attivato nel primo semestre 2026 i gate di conformità CI e i suggerimenti IDE, riducendo il tempo medio pro-capite per la revisione di conformità del codice AI da 45 minuti a 8 minuti per sessione. Il punto chiave non è che la “revisione” sia più veloce, ma che il codice generato da AI “non sbagli” a monte.

5.3 Conformità a doppia velocità: stratificazione per adattarsi al ritmo del business

L’ultimo dettaglio: la conformità non va gestita con un approccio unico per tutti. Dividete le regole in due livelli in base al rischio:

  • Regole ad alto rischio (che coinvolgono fondi dei clienti / decisioni algoritmiche / dati transfrontalieri / requisiti di sicurezza critici) richiedono controlli rigorosi: revisione manuale obbligatoria + doppia conferma AI + registrazione presso il Change Advisory Board
  • Regole a basso rischio (codice CRUD standard / utility / generazione di documentazione) seguono controlli self-service: basta la verifica automatica in CI, nessuna revisione manuale richiesta

Il control plane di Agent 365 di Atos è essenzialmente questa stratificazione: agenti di livello diverso sono vincolati a requisiti di governance diversi. Stratificare le regole di conformità per livello di rischio permette ai team di business di percepire che “la conformità non blocca tutto”.

Il quadro complessivo di queste tre cose: incorporare la conformità non significa aggiungere un passaggio procedurale, ma riprogettare la struttura e gli incentivi del team. Se il vostro ufficio compliance è ancora in modalità “revisione a posteriori”, l’adozione guidata dalle regole si bloccherà proprio sullo step più difficile — quello dell’”istituzionalizzazione”. L’ufficio compliance deve prima trasformarsi, perché l’adozione guidata dalle regole possa funzionare senza intoppi.

6. Domande probabili

“Abbiamo già delle linee guida di codifica — qual è la differenza?”

Le linee guida di codifica riguardano “come scrivere codice”; l’adozione guidata dalle regole riguarda “come collaborare con l’AI”. Le linee guida di codifica non includono: regole di business, requisiti di conformità, policy d’uso dell’AI. L’adozione guidata dalle regole rende esplicito l’intero flusso di collaborazione tra umani e AI — non è una guida di stile per il codice.

“Scrivere delle linee guida non rallenterà lo sviluppo?”

A breve termine sì, a lungo termine no. I dati di CodeRabbit danno una risposta chiara: il rischio di difetti nel codice AI senza vincoli è circa 1,7 volte più alto, e quello di vulnerabilità di sicurezza 2,74 volte. Nel settore finanziario, una revisione per conformità costa 2-4 settimane di rilavorazione — evitare una sola di queste ripetizioni ti dà il tempo per scrivere un mese di linee guida. I 250 milioni di dollari risparmiati da EY sono la prova concreta che questo approccio funziona quando diventa una capacità organizzativa.

“E se nel nostro team nessuno sa scrivere linee guida?”

Non devi partire da zero. GitHub Spec Kit, Claude Code Superpowers e AWS Kiro offrono tutti dei template. Devi solo inserire le regole specifiche della tua organizzazione — per la maggior parte si tratta di regole di conformità e sicurezza, che i dipartimenti di compliance e security hanno già scritto da tempo. Il problema è che non sono mai state messe in un formato che l’AI potesse leggere.

“Ci sono così tanti strumenti AI, quale scegliamo?”

Non è importante. Scegliete quello che già usate. Le specifiche guidano, non vincolano agli strumenti: CLAUDE.md funziona in Claude Code, Cursor e Codex; AGENTS.md gira nell’ecosistema OpenAI; constitution.md è indipendente dal modello. Il punto è scrivere le specifiche, non cambiare strumento. EY sta implementando nell’ecosistema Microsoft, Atos pure: la scelta dello strumento è solo superficie, l’uniformità della governance è la sostanza.

“L’EU AI Act diventa pienamente applicabile ad agosto 2026: questo ci riguarda?”

Sì. L’EU AI Act entra in piena applicazione il 2 agosto 2026, con requisiti obbligatori per i sistemi di IA ad alto rischio (inclusi credito, tariffazione assicurativa, selezione del personale e infrastrutture critiche): gestione del rischio (Art. 9), governance dei dati (Art. 10), trasparenza documentale (Art. 11-13), supervisione umana (Art. 14), accuratezza/robustezza (Art. 15). Le sanzioni arrivano fino a 35 milioni di euro o al 7% del fatturato globale. Per le aziende cinesi che si espandono all’estero, il mercato UE è una prova obbligata; per quelle domestiche, il quadro dell’EU AI Act è anche il riferimento più adottato a livello globale — puoi anche non esservi direttamente soggetto, ma difficilmente puoi ignorarne gli effetti di trasmissione su fornitori, partner e attività transfrontaliere (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

“Il parallelo interno: l’UE regola l’IA, e da noi?”

A livello nazionale, la governance dell’IA generativa si basa su un trio di strumenti: “registrazione degli algoritmi + revisione dei dati di addestramento + valutazione della sicurezza”, con il Regolamento provvisorio sulla gestione dei servizi di IA generativa (entrato in vigore ad agosto 2023) come pilastro centrale. La differenza più grande tra i due approcci non sta nel dettaglio delle disposizioni, ma nella filosofia legislativa:

DimensioneEU AI ActRegolamento cinese sulle “Misure di gestione dei servizi di IA generativa”
Natura giuridicaRegolamento orizzontale (si applica a tutti i sistemi di IA)Regola verticale (focalizzata sui servizi di IA generativa)
Classificazione del rischio4 livelli (inaccettabile / alto / limitato / minimo)2 livelli (che coinvolgono la sicurezza dell’opinione pubblica / uso commerciale generale)
Tempistica della supervisioneEx ante (registrazione già in fase di sviluppo)Ex post (registrazione dopo il lancio + registrazione dell’algoritmo)
TrasparenzaAlta (richiede la pubblicazione di un riepilogo delle fonti dei dati di addestramento e delle model card)Media (richiede la conformità dei dati di addestramento ma non impone la divulgazione delle fonti)
Massima sanzione7% del fatturato globale o 35 milioni di euroSospensione del servizio / sanzioni pecuniarie (di solito multipli dei proventi illeciti)
Ambito di applicazioneTutte le imprese che superano la soglia di fatturato globaleTutti i soggetti che forniscono servizi sul territorio cinese

In pratica, i sistemi di IA degli istituti finanziari cinesi sono normalmente soggetti a tre livelli di regolamentazione simultanei — le Misure per la gestione dell’IA generativa (livello di base) + le Misure per la gestione dei prestiti online delle banche commerciali (livello operativo) + la classificazione di protezione della sicurezza informatica (等保, dengbao) + la registrazione degli algoritmi (livello di conformità). Questo significa che, per chi opera in Cina, non si può semplicemente ricalcare il framework dell’EU AI Act: bisogna integrare tutte e tre le direttrici — conformità dei dati di addestramento, registrazione degli algoritmi e reporting normativo — direttamente nel file CLAUDE.md.

Per chi si espande all’estero: i quattro pilastri dell’EU AI Act — gestione del rischio, governance dei dati, trasparenza documentale e supervisione umana — sono esattamente le direzioni verso cui anche la regolamentazione cinese si sta allineando. Già nel 2025, alcuni feedback sulle registrazioni di IA generativa da parte della Cyberspace Administration of China (CAC) mostrano un’evidente assimilazione del livello di dettaglio europeo. Scrivere oggi una policy compatibile con l’EU AI Act significa, con alta probabilità, essere già allineati anche con l’inasprimento normativo cinese dei prossimi tre anni (annunci di registrazione CAC 2025-2026; scadenza conformità EU AI Act: giugno 2026).

7. Cosa significa per i decision maker

Primo punto: scrivere una policy di progetto in un file CLAUDE.md o AGENTS.md è l’investimento di ingegneria con il più alto ROI nell’era dell’IA.

Il costo è di 3-8 settimane per organizzare il materiale, più 1-2 settimane per la documentazione. Il ritorno: il limite superiore del rischio di difetti si riduce a circa 1,7 volte, le vulnerabilità di sicurezza calano di 2,74 volte, e il tasso di rilavorazione scende di oltre il 40%. Nel settore finanziario, bastano una sola revisione di conformità evitata (2-4 settimane) a coprire questo costo. EY ha distribuito Copilot a 150.000 dipendenti risparmiando 250 milioni di dollari — ma solo perché prima aveva definito degli standard.

Lezione 2: La standardizzazione è una capacità organizzativa, non una scelta di strumenti.

Che tu scelga GitHub Spec Kit o Claude Code non è ciò che conta. Ciò che conta è se hai definito “come la nostra organizzazione collabora con l’AI”. Senza questo, anche il miglior strumento si limita a far accumulare debito tecnico più velocemente.

Lezione 3: Integra gli standard nei processi organizzativi, non affidarti ai singoli.

Se gli standard vivono solo nella testa di un ingegnere senior, si perdono appena quella persona cambia ruolo o azienda. Devono essere incorporati nella documentazione del repository, nei gate CI, nelle configurazioni condivise del team e nelle piattaforme di governance degli agenti. Gli standard devono diventare un asset organizzativo, non una competenza individuale. I 19.000 agenti di Atos operano in 54 paesi perché la governance non è “qualcuno che capisce”, ma “il sistema che impone”.

Lezione 4: I gate contano più della velocità.

GitHub Spec Kit 的 gate a cinque fasi, la regola di Superpowers “niente codice finché il test non fallisce”, l’obbligo di Kiro di “non si parte senza spec”: sono tutti modi per mettere un freno tra l’AI e il risultato finale. Più l’AI diventa capace, più la governance deve venire prima. Il 78% di incidenti nel report New Relic 2026 è il prezzo pagato da quel 62% di team che rilascia senza revisione. I CIO del settore finanziario lo capiscono meglio di chiunque altro: il vostro Change Advisory Board (Change Advisory Board (CAB)), le procedure di registrazione degli algoritmi, i test di conformità (ISO 27001 + ACN 安全指引, il sistema cinese di classificazione e verifica della sicurezza informatica) — sono tutti gate prima della messa in produzione. Anche il codice generato dall’AI ha bisogno di gate simili, e devono essere ancora più a monte.

Auto-verifica inversa (senza abbellire la risposta): il codice generato dall’AI che producete, la revisione di conformità richiede spesso rilavorazioni? Qual è stato l’ultimo problema causato da codice AI? Se chiedete al responsabile tecnico “come collaboriamo con l’AI”, sa produrvi un documento? Se non sapete rispondere a una di queste tre domande, significa che la governance basata su specifiche non è ancora operativa — prima le specifiche, poi gli strumenti.

Tre domande da coach per i decision maker

Chiudo con tre domande — non una checklist, ma spunti che potete usare direttamente nelle discussioni col vostro team:

  1. “Se domani tutti gli strumenti di AI venissero spenti, di quanto calerebbe la qualità del codice del vostro team?” — Questa domanda rivela il valore reale dell’engineering enablement: se la risposta è “calerebbe significativamente”, significa che le vostre linee guida non sono ancora state interiorizzate; se la risposta è “quasi per niente”, allora l’approccio basato su standard sta già funzionando.
  2. “Nel vostro progetto di engineering enablement, il team compliance svolge il ruolo di ‘guardiano’ o di ‘enabler’?” — Se la risposta è “guardiano”, la vostra velocità di implementazione sarà bloccata dai colli di bottiglia delle approvazioni; se la risposta è “enabler”, avete già intrapreso il percorso descritto nella sezione 5.2.
  3. “Tra 12-18 mesi, come cambierà la dimensione del vostro team?” — La risposta del Microsoft WTI 2026 è che l’82% dei leader utilizzerà agenti AI per “espandere” la forza lavoro. Se la vostra risposta è “non cambierà”, o il vostro business non sta crescendo, oppure il vostro design organizzativo non sta sfruttando i benefici dell’engineering enablement.

Non esistono risposte giuste o sbagliate a queste tre domande. Ma la direzione delle risposte è più importante delle risposte stesse.

Prossimi passi

Questo è il sesto articolo della serie “La trasformazione dell’ingegneria del software nell’era dell’AI”. Siamo partiti da Conway (l’organizzazione determina l’architettura), passando per Team Topologies (come progettare l’organizzazione), fino al collo di bottiglia che si sposta (il problema non è la codifica ma la verifica). Oggi abbiamo parlato di engineering enablement (usare la documentazione per vincolare il comportamento dell’AI).

Nel prossimo articolo (il settimo), esamineremo l’infrastruttura sottostante che rende possibile tutto questo: il protocollo MCP (Model Context Protocol). Perché il protocollo open source di Anthropic è stato definito “l’USB-C dell’IA”, perché OpenAI, Google e Microsoft lo hanno tutti adottato, e come consente l’interoperabilità tra più strumenti e più agenti.

Vuoi applicare questo approccio alla tua azienda?

Quando l’approccio normativo entra in azienda, i problemi concreti da risolvere sono di solito pochi e specifici: come far confluire le regole chiave in CLAUDE.md / AGENTS.md, come adeguare il codice esistente, come integrare la conformità normativa, e con quali metriche valutare il progetto pilota.

Offriamo tre tipi di collaborazione:

  • Formazione aziendale: sulla base dei tuoi progetti reali, aiutiamo a strutturare la documentazione normativa, progettare i gate CI, definire il percorso di integrazione della conformità e costruire il meccanismo di governance.
  • Consulenza mirata: ci concentriamo su una decisione specifica, ad esempio “la nostra azienda dovrebbe iniziare scrivendo CLAUDE.md / AGENTS.md?” o la definizione delle priorità per la messa a norma del codice esistente.
  • Interventi per il management e keynote di settore: su strumenti di programmazione con IA, approccio normativo, governance organizzativa e Frontier Firms.

L’articolo fornisce un quadro generale di riferimento. L’implementazione concreta richiede comunque una riprogettazione basata sui requisiti di conformità aziendali, i confini normativi, la maturità ingegneristica e i processi di delivery esistenti. Per collaborazioni: coach@iaiuse.com.

Approfondimento: Metodologia Insegna il Metodo v1.0 (Imparare l’AI Lentamente 187), che presenta sistematicamente il framework in 7 fasi per la trasformazione AI delle imprese.

Informazioni su questa serie

“La trasformazione dell’ingegneria del software nell’era dell’AI” è una serie di ricerca rivolta a CIO, CDO, CTO e responsabili della trasformazione digitale nei settori telecomunicazioni, finanza, manifattura ed e-commerce. La serie comprende 18 articoli e si concentra su come gli strumenti di programmazione AI, la governance basata su standard e la governance organizzativa influenzino i processi di delivery del software, le strutture organizzative e la maturità ingegneristica.

La serie monitora costantemente paper accademici, materiali dei vendor e report di settore. Il database di ricerca conta oltre 200 fonti, e per ogni giudizio chiave viene indicato il livello di evidenza, distinguendo il più possibile tra fatti verificati, affermazioni dei vendor, osservazioni di settore e deduzioni dell’autore.

Vanto di quasi 8 anni di esperienza in consulenza per grandi imprese e analisi di business, con un passato in IBM e progetti nei settori telecomunicazioni, finanza, assicurazioni e manifattura. Successivamente, ho continuato a operare in prima linea nello sviluppo di prodotti per operatori, prodotti internet e applicazioni AI, occupandomi di analisi dei requisiti, product design e implementazione cross-funzionale.

Questa serie di riflessioni su governance basata su standard, organizzazione e ingegnerizzazione nasce da queste esperienze pratiche, incrociate con ricerca pubblica e casi di settore per una validazione incrociata. I contenuti relativi a progetti specifici sono stati resi anonimi; alcuni scenari di settore sono ricostruzioni di problemi tipici, con le relative fonti elencate in fondo al documento.

Dietro questa pubblicazione c’è in realtà un piccolo team — io e 1-2 colleghi con cui collaboro da tempo, ognuno dei quali si occupa rispettivamente di ricerca sugli strumenti di coding con AI, analisi di casi di governance organizzativa e coaching conversation. La maggior parte dei progetti in cui “abbiamo accompagnato le aziende” nel testo sono stati consegnati insieme da noi. I confini di conformità dei clienti e i nomi delle persone restano comunque non menzionati; l’anonimato è preservato per lasciare spazio a futuri colleghi con cui collaboreremo.

Fonti di riferimento (tutte verificate, con livello di evidenza indicato per ciascuna)

  • CodeRabbit (2025.12). State of AI vs Human Code Generation Report. I problemi nel codice generato dall’AI sono 1,7 volte superiori a quelli del codice umano (10,83 vs 6,45 problemi per PR), con un rapporto di 1,75× per logica/correttezza, 1,64× per qualità del codice, 1,57× per sicurezza, 1,88× per gestione delle password e 2,74× per XSS. Livello di evidenza: primario. Fonte: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263

  • The Register (17.12.2025). Riporta il report completo di CodeRabbit: analisi di 470 PR open source, con PR assistite da AI che presentano 10,83 problemi contro i 6,45 dei PR puramente umani. Livello di evidenza: secondario. Fonte: URL sopra indicato

  • CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap” — il 2026 sarà l’anno della svolta: si passa dalla “velocità di generazione del codice” alla “qualità e governance del codice”. Livello di evidenza: secondario. Fonte: https://tfir.io/ai-code-quality-2026-guardrails

  • New Relic (2026). The 2026 State of AI Coding Report. Il 78% dei team registra più incidenti dopo aver messo in produzione codice generato dall’AI; il 62% dei leader tecnici ammette che i propri team “pubblicano con fiducia senza revisione” codice AI; il 96% ritiene l’osservabilità indispensabile. Livello di evidenza: primario (report del vendor). Fonte: https://newrelic.com/resources/report/2026-state-of-ai-coding

  • Microsoft 2026 Work Trend Index Annual Report (2026.5.5). Sondaggio su 20.000 professionisti che usano l’AI, in 10 Paesi; l’82% dei leader prevede di espandere la forza lavoro con agenti AI entro 12-18 mesi; l’81% prevede un’integrazione media o elevata degli agenti AI; il 24% ha già implementato a livello enterprise; il 49% delle conversazioni con Copilot supporta il lavoro cognitivo; il 58% degli utenti AI dichiara di aver fatto “cose che un anno fa non sarebbero state possibili”, percentuale che sale all’80% tra i Frontier Professionals. Livello di evidenza: primario. Fonte: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf

  • Microsoft FY26 Retrospective: dall’esperimento AI alla trasformazione di frontiera (28 luglio 2026). EY ha distribuito Microsoft 365 Copilot a 150.000 dipendenti, generando un risparmio di 2,5 milioni di ore e circa 250 milioni di dollari; l’implementazione è poi stata estesa a 400.000 dipendenti a livello globale, con un aumento della velocità del 95%, una riduzione del 37% dei costi operativi finanziari e una diminuzione fino al 90% dei flussi di lavoro manuali. Atos ha implementato Copilot in 56 paesi per 56.000 dipendenti, affiancando 19.000 agenti AI, con un piano di controllo unificato per identità, sicurezza, conformità e governance. Livello di evidenza: livello 1 (revisione ufficiale Microsoft). Fonte: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Collaborazione strategica tra Atos Group e Microsoft (2026.6.9). Atos implementa Microsoft 365 E7 (Frontier Suite) per 56.000 dipendenti in 56 paesi, con 19.000 agenti AI; piano di controllo unificato per Entra/Defender/Intune/Purview/Agent 365. Livello di evidenza: primario (comunicato stampa congiunto). Fonte: 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 (open source nel settembre 2025, in evoluzione nella prima metà del 2026). Processo a 5 fasi con gate /speckit.constitution → /specify → /plan → /tasks → /implement, più /clarify /analyze; indipendente dal modello (funziona con Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code). Livello di evidenza: primario. Fonte: https://github.com/github/spec-kit

  • AWS Kiro (rilasciato a luglio 2025, in evoluzione nella prima metà del 2026). Workflow in tre fasi: requisiti → progettazione → attività; lo spec attiva azioni predefinite degli agenti; senza spec non si può avviare. Livello di evidenza: primario. Fonte: https://kiro.dev/

  • OpenAI Codex + AGENTS.md + Skills (2025-2026). Codex 2026.6 ha superato i 5 milioni di utenti attivi settimanali, di cui il 20% non sviluppatori; AGENTS.md + Skills formano un set di istruzioni componibili. Livello di evidenza: primario (annuncio ufficiale OpenAI). Fonte: https://developers.openai.com/codex/skills

  • Claude Code (Anthropic, primo semestre 2026). Sistema basato su CLAUDE.md + .claude/rules/ + Skills; entrato nel marketplace ufficiale Anthropic a febbraio 2026; il repository GitHub delle Skills ha raggiunto 112.000 stelle; il round di serie G del febbraio 2026 ha rivelato ricavi annualizzati di 2,5 miliardi di dollari. Livello di evidenza: primario. Fonte: https://code.claude.com/docs/en/claude-directory

  • JetBrains AI Pulse Survey (2026.1). Sondaggio su 10.000+ sviluppatori professionisti a livello globale, localizzato in 8 lingue; CSAT di Claude Code al 91% / NPS 54 (il più alto del settore); adozione di Claude Code sul posto di lavoro al 18% (cresciuta di 6 volte dal 3% in 9 mesi), 24% in Nord America; Copilot al 29% di adozione sul posto di lavoro ma in stagnazione; Cursor al 18%. Livello di evidenza: primario. Fonte: https://www.jetbrains.com/lp/tools/ai-tools/

  • Pragmatic Engineer Newsletter (2026.2). Sondaggio su 15.000 sviluppatori; il 46% ha scelto Claude Code come “preferito in assoluto”, Cursor al 19%, Copilot al 9%. Livello di evidenza: primario. Fonte: https://newsletter.pragmaticengineer.com/

  • Alibaba Qoder (2025.8 → 2026.7). Pubblicato da Alibaba nell’agosto 2025; il 15 maggio 2026, Qoder 1.0 viene aggiornato ad Autonomous Agent Development Workbench; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; il 28 maggio 2026, Cloud Agents (runtime per agenti gestiti); il 21 luglio 2026, Qoder Security; a maggio 2026, oltre 5 milioni di utenti globali; integrazione CLI con DingTalk; il 20 maggio 2026, Tongyi Lima viene rinominato Qoder CN. Livello di evidenza: primario. Fonti: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525

  • vibecoding.app / thebcms.com / tfir.io (prima metà 2026). Comandi in cinque fasi per Spec Kit, confronto e valutazione degli strumenti SDD, notazione EARS. Livello di evidenza: secondario (valutazione di terze parti). Fonte: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development

  • EU AI Act / Code of Practice (piena applicazione dal 2.8.2026). Scadenza conformità per i sistemi di IA ad alto rischio fissata al 2.8.2026; i modelli GPAI esistenti hanno tempo fino al 2.8.2027; sanzioni fino a 35 milioni di euro o al 7% del fatturato globale annuo; Artt. 9-15 su gestione del rischio, governance dei dati, trasparenza documentale, supervisione umana, accuratezza e robustezza. Livello di evidenza: primario (regolamento + analisi di conformità secondaria). Fonte: 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). Il 44% dei problemi ha origine da una mancanza di contesto. Livello di evidenza: secondario (report del vendor). Fonte: https://www.qodo.ai/reports/state-of-ai-code-quality/

Slowly Learning AI: Una guida per i CIO e i decisori delle industrie di telecomunicazioni, finanziarie, manifatturiere e e-commerce

Introduzione

Come consulente di ricerca per l’IAUSE, questo blog è dedicato ai CIO e ai decisori delle industrie di telecomunicazioni, finanziarie, manifatturiere e e-commerce. In questo articolo, esploreremo le sfide e le opportunità dell’intelligenza artificiale (IA) e forniremo esempi di come le aziende possono implementare la tecnologia dell’IA per migliorare la loro efficienza e competitività.

La necessità di una strategia di IA

La tecnologia dell’IA sta cambiando rapidamente e le aziende devono essere in grado di adattarsi per rimanere competitive. Secondo un rapporto di Gartner, il 75% delle aziende ha già implementato la tecnologia dell’IA in qualche forma. Tuttavia, solo il 10% delle aziende ha una strategia di IA chiara e ben definita.

La strategia di IA

Una strategia di IA efficace deve essere basata su una comprensione profonda delle esigenze e delle sfide dell’azienda. Ciò richiede una collaborazione tra i dipartimenti di tecnologia, marketing e vendita per identificare le aree in cui l’IA può fornire più valore.

Esempi di implementazione dell’IA

  • Telecomunicazioni: AT&T ha implementato la tecnologia dell’IA per migliorare la sua capacità di gestione dei dati e di analisi dei dati. Ciò ha permesso all’azienda di migliorare la sua efficienza e di offrire servizi più personalizzati ai clienti.
  • Finanziarie: Deutsche Bank ha implementato la tecnologia dell’IA per migliorare la sua capacità di analisi dei dati e di gestione dei rischi. Ciò ha permesso all’azienda di migliorare la sua efficienza e di offrire servizi più sicuri ai clienti.
  • Manifatturiere: Siemens ha implementato la tecnologia dell’IA per migliorare la sua capacità di gestione dei dati e di analisi dei dati. Ciò ha permesso all’azienda di migliorare la sua efficienza e di offrire prodotti più innovativi ai clienti.
  • E-commerce: Amazon ha implementato la tecnologia dell’IA per migliorare la sua capacità di gestione dei dati e di analisi dei dati. Ciò ha permesso all’azienda di migliorare la sua efficienza e di offrire servizi più personalizzati ai clienti.

Conclusioni

La tecnologia dell’IA sta cambiando rapidamente e le aziende devono essere in grado di adattarsi per rimanere competitive. Una strategia di IA efficace deve essere basata su una comprensione profonda delle esigenze e delle sfide dell’azienda. Gli esempi di implementazione dell’IA sopra menzionati dimostrano come le aziende possono utilizzare la tecnologia dell’IA per migliorare la loro efficienza e competitività.

Risorse

]]> Problemi nel codice AI 1,7×, vulnerabilità 2,74× — l'AI non vede le tue regole. Spec Kit, Kiro, Codex, Claude Code, Qoder convergono nel 2026 H1 su CLAUDE.md. 【규범 주도】Spec-Driven Development——스펙 작성은 AI 시대 ROI가 가장 높은 엔지니어링 행동이다 AI 시대 소프트웨어 엔지니어링의 변화——천천히 배우는 AI177 https://iaiuse.com/ko/posts/%EC%8A%A4%ED%8E%99%EC%A3%BC%EB%8F%84%EA%B0%9C%EB%B0%9C-spec-driven-development-%EC%8A%A4%ED%8E%99%EC%9E%91%EC%84%B1%EC%9D%B4-ai%EC%8B%9C%EB%8C%80-roi-%EC%B5%9C%EA%B3%A0-%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EB%A7%81-%ED%99%9C%EB%8F%99-ai%EC%8B%9C%EB%8C%80-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EB%A7%81-%EB%B3%80%ED%99%94 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z

데이터 출처: CodeRabbit 2025.12 / New Relic 2026 보고서, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms 발표, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. 사례는 대표적인 시나리오를 요약한 것으로, 특정 기업을 지칭하지 않음.

당신의 가장 큰 실수는 도구를 사지 않은 게 아니라, CLAUDE.md를 쓰지 않은 것이다

한 시중은행의 CIO가 저에게 이렇게 털어놓았습니다. AI 도구도 사고, 모델도 배포하고, 인력 교육도 마쳤는데, 2026년 상반기 내내 납기가 거의 줄지 않았다고요. 핵심 시스템 담당 팀장은 더 직설적이었습니다. “AI가 작성한 코드는 쓸 만한데, 매번 처음부터 다시 고쳐야 합니다. AI가 우리 은행의 규칙을 모르고, 규제 요건을 모르고, 30년 묵은 레거시 시스템과 어떻게 연동해야 하는지도 모릅니다.”

문제는 AI가 충분히 강력하지 않다는 것이 아니라, 규칙을 코드로 명시하지 않았다는 데 있다. CodeRabbit이 2025년 12월 470개 오픈소스 PR을 분석해 발표한 수치는 업계에서 널리 인용된다. AI가 협업한 PR에는 평균 10.83개의 문제가 있었고, 순수 인간이 작성한 PR에는 6.45개가 있었다. 약 1.7배, 즉 인간보다 버그가 70% 더 많았다. 2026년이 되어도 상황은 반전되지 않았다. New Relic의 《2026 State of AI Coding Report》에 따르면, 78%의 팀이 AI 코드를 배포한 이후 더 많은 장애를 보고했고, 62%의 기술 리더는 팀이 “자신감 있게, 그러나 라인별 리뷰 없이 AI 코드를 바로 배포한다”고 인정했다(New Relic 공식 보고서 2026, 0.866 score, 1차 출처). 두 데이터는 같은 사실을 말한다. AI에게 부족한 것은 능력이 아니라 맥락이다.

2026년 8월 현재, 모든 “AI 전환 가속화” 서사는 다음 대비 속에서 읽혀야 한다.

| 진영 | 진행 상황 (2026 H1) | 반례 (2026 H1) |
|—|—|—|—|
| EY | Microsoft 365 Copilot을 150,000명의 임직원에게 확대 배포, 250만 시간 / 2.5억 달러 절감; 글로벌 40만 임직원으로 확장 예정 | 다만 95% 업무 속도 향상, 37% 재무 운영 비용 절감의 전제가 “규범 선행”임을 동시에 인정 |
| Atos | 54개국 / 56,000명 임직원 대상 배포 완료; 19,000개 AI 에이전트 동시 운영, 통합 ID/보안/컴플라이언스/거버넌스 컨트롤 플레인 구축 | “Agent 365 거버넌스 역량을 먼저 구축한 뒤 확장한다”는 원칙을 고수 |
| Microsoft 자체 | 2026 Work Trend Index: 리더의 82%가 12~18개월 내 AI 에이전트로 노동력 확장 계획 | 동시에 “개인 사용 대비 조직 변화의 속도가 뒤처지고 있다”고 인정 — Frontier Firm 개념의 핵심 모순 |

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

이 두 그룹의 대조가 보여주는 것은 단 하나다. 규범 없이 규모를 키우는 것은 리스크에 N을 곱하는 것과 같다. EY/Atos/Microsoft의 “빠름”은 모델이 빠른 것이 아니라, “조직이 AI를 어떻게 쓸지에 대한 답을 먼저 끝냈다”는 뜻이다. 이것이 Spec-Driven Development(SDD, 스펙 기반 개발)가 2026년 상반기에 진짜 주류가 된 배경이다. 엔지니어가 문서를 좋아해서가 아니라, 스펙을 쓰지 않으면 19,000개 에이전트가 존재하는 환경에서 살아남을 수 없기 때문이다.

이 글은 세 가지를 명확히 다룬다: 1) AI 코드의 결함이 왜 사람이 작성한 코드보다 1.7배 이상 심각한가; 2) GitHub, AWS, OpenAI, Anthropic, Alibaba 다섯 개 플랫폼이 2026년 상반기에 어떻게 같은 패러다임, 즉 문서로 AI의 행동을 제약하는 방식으로 수렴했는가; 3) 스펙 기반 개발이 왜 도구 선택이 아닌 조직 역량인가, 그리고 2026년 상반기 적용의 3단계는 무엇인가.

AI 코드 vs 인간 코드: 결함 분포 (470개 오픈소스 PR 분석) CodeRabbit 2025.12 보고서｜모든 수치는 AI/인간 배수비 (기준선 1.0)

막대 길이 = AI 결함이 인간의 배수; 기준선 1.0× = 인간 수준

기준 1.0×

전체 문제 수

1.7×
AI 10.83 vs 인간 6.45 / PR

로직/정확성 오류

1.75×

코드 품질/유지보수성

1.64×

보안 발견 (종합)

1.57×

비밀번호 처리 부적절

1.88×

XSS 취약점

2.74×
↑ 최고

규범 제약 없는 AI 코드, 모든 차원에서 인간보다 높음
금융/통신 = 규정 준수 대사, 비밀번호 관리, 민감 필드 암호화, AI 모두 놓침

AI 부족한 로컬 비즈니스 로직: 모델은 통계적 추론으로 코드 패턴을 처리하지, 의미를 이해하지 못한다

“AI는 로컬 비즈니스 로직이 부족하다. 모델은 코드 패턴을 통계적으로 추론할 뿐, 의미적으로 이해하지 못한다. 엄격한 제약이 없으면, 시니어 엔지니어가 내면화한 시스템 규칙을 놓친다.”

이 문장은 CodeRabbit이 자체 AI 코딩 플랫폼(AI 코드 리뷰 전문 기업)에서 왜 다른 회사보다 먼저 이 데이터를 볼 수 있었는지를 설명한다. 그들은 매일 수천 개의 PR을 검토하고, AI가 작성한 코드가 어떤 모습인지 매일 확인한다. 가장 중요한 발견은 총계가 아니라 분포다:

  • 로직/정확성 +75%: 비즈니스 로직 오류, 의존성 오류, 제어 흐름 오류, 설정 오류 — 이런 문제는 테스트에서 드러나지 않을 수 있지만, 프로덕션 환경에서는 장애로 이어진다.
  • 코드 품질 +64%: 네이밍 불일치, 구조 불명확, 프로젝트 패턴 위반 — 이것이 “가장 큰 차이를 만드는 카테고리”다. 시니어 엔지니어는 한눈에 “이건 우리 팀 스타일이 아니다”를 알아본다.
  • 보안 +57%(XSS 계열이 가장 높아 2.74×): 비밀번호 처리 부적절(1.88×), 안전하지 않은 객체 참조(1.91×), 민감 정보 노출, 안전하지 않은 역직렬화(1.82×) — 금융 업계에서 이건 “쓸 수 있느냐”의 문제가 아니라 “출시할 수 있느냐”의 문제다.

문제는 AI가 충분히 강력하지 않다는 게 아니다. AI가 보지 못한다는 거다.

그 CIO가 실제로 부딪힌 지점으로 돌아가 보자. AI가 금융 코어 시스템에서 만들어낸 세 가지 구체적 실패 사례다.

첫째, AI는 30년 된 대사 로직을 보지 못한다. 은행의 리스크 관리 규칙은 코어 시스템의 스토어드 프로시저에 박혀 있다. 30년 전에 작성됐고, 지금은 아무도 전부 기억하지 못한다. AI가 생성한 코드 로직은 겉보기에 문제없어 보이지만, 프로덕션 환경에서 아무도 기억하지 못하는 대사 점검 로직에 걸려 거래 배치 전체가 실패한다.

둘째, AI는 컴플라이언스 제약을 보지 못한다. 비밀번호는 반드시 키 관리 시스템을 거쳐야 하고, 민감 필드는 암호화 저장이 필수이며, 로그에 고객 정보를 출력해서는 안 된다. 이는 규제상의 하드 제약으로, 내부 제도에 명문화되어 있다. AI는 이걸 모르기 때문에, 작성한 코드는 실행은 되지만 컴플라이언스 심사를 통과하지 못한다.

셋째, AI는 당신의 기술 부채를 보지 못한다. 30년 된 레거시 시스템은 자체적인 인터페이스 프로토콜을 사용하는데, 문서는 이미 오래전에 유실됐다. AI는 표준 RESTful 규약에 맞춰 코드를 작성하고, 배포 후에야 인터페이스가 맞지 않는다는 걸 발견한다. 재작업에 2주가 걸린다.

New Relic의 또 다른 수치로 돌아가 보자. 62%의 팀이 “자신 있게 검토 없이” AI 코드를 배포하고, 78%는 배포 후 더 많은 장애를 보고했다. 이 두 숫자를 합치면 결국 이렇게 읽힌다. AI 코드의 결함률 자체는 문제가 아니다. “AI 코드에 어떤 결함이 있는지 내가 모른다”는 것이 진짜 문제다.

일반적인 시나리오: 한 주식회사 은행이 AI를 도입해 핵심 시스템의 리스크 관리 모듈을 개발한 결과, 3개월 만에 컴플라이언스 심사 반려율이 눈에 띄게 상승했다. 주요 문제는 비밀번호 관리, 민감 필드 암호화, 로그 컴플라이언스 등 내부 규칙이었다. 이 규칙들은 모두 내부 문서에 적혀 있었지만, AI는 이를 볼 수 없었다. 이후 팀이 핵심 규칙을 CLAUDE.md로 작성하자 반려율이 크게 떨어졌다.

2. 5대 플랫폼의 2026 H1: 같은 결말을 향한 “규범 주도”

2025년 7월 GitHub가 Spec Kit을 출시했고, 2026년 초 AWS Kiro, OpenAI Codex, Anthropic Claude Code가 모두 이를 갖췄다. 2026년 5월, Alibaba Qoder는 “Spec-Driven Workflow”를 제품 포지셔닝에 포함시켰다. 5대 플랫폼은 2026 H1에 동일한 패러다임에 도달했다 — 문서로 AI의 행동을 제약하는 것. 이는 어느 한 회사의 발명이 아니라, “AI 코드 품질 위기”에 대한 업계의 집단적 대응이다.

5대 플랫폼의 규범 기반 경로 (2025-2026 H1) GitHub Spec Kit 오픈소스 2025.9 constitution.md 5단계 게이팅: constitution → specify → plan → tasks → implement 모델 무관, 8+ 에이전트 연동 Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md 3단계 워크플로우: 요구사항 → 설계 → 태스크 spec 기반 IDE 워크플로우 내장 훅 트리거 자동 에이전트 컴플라이언스/감사 훅 사전 내장 spec 없으면 시작 불가 OpenAI Codex 2025-2026 AGENTS.md + Skills 시스템 조합형 명령어 세트 팀 단위 공유 설정 주간 활성 5M+ (2026.6) 비개발자 비중 20% 프로그래밍에서 범용 에이전트로 Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + Skills（공식 마켓 2026.2） + MCP 생태계 CSAT 91% / NPS 54 $2.5B ARR（2026.2） GitHub 11.2만 stars Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Quest Mode 자율 실행 + Expert Mode 팀 + RepoWiki 컨텍스트 5M+ 글로벌 사용자（2026.5） 2026.7.21 Qoder Security DingTalk CLI 연동 완료 공통 패러다임: "우리가 AI와 어떻게 협업하는지"를 문서로 명시해 저장소에 배치 모든 사람과 모든 AI 에이전트가 동일한 규범을 기준으로 작업하게 함 — 이것이 규범 주도의 본질

각 플랫폼의 2026 H1 최신 움직임을 하나씩 살펴보자.

**GitHub Spec Kit: 레퍼런스 구현체이자 5단계 게이트웨이 구조다. 2025년 9월에 오픈소스로 공개된 이후 2026년 상반기까지 벌써 산업계 레퍼런스 구현체로 자리 잡았다. 핵심은 5개+2개 구조다. /speckit.constitution(불가역적 원칙), /speckit.specify(무엇을 왜 하는가), /speckit.plan(어떻게 바꿀 것인가), /speckit.tasks(작업 쪼개기), /speckit.implement(실행 그리고 /clarify과 /analyze이 뒤를 따른다. 이 설계의 핵심은 모델 비종속성이다. 즉, 동일한 spec/plan/tasks 파일이 특정 실행 에이전트에 묶이지 않는다는 뜻이다. Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI,

AWS Kiro: 규범 주도 개발을 IDE에 내장하다. 2025년 7월 출시, 2026년 상반기에는 완전한 Agent IDE로 진화. 3단계 워크플로우: 요구사항 → 설계 → 태스크. Spec Kit과의 차이는 “훅(Hook)”에 있다. Kiro의 spec 파일은 사전 정의된 에이전트 액션을 트리거하여, 컴플라이언스/감사/배포처럼 외부 시스템이 필요한 단계를 워크플로우에 미리 심어둘 수 있다. 팀에 규범 작성을 강제하고 싶다면 Kiro를 선택하라 — spec을 작성하지 않으면 Kiro가 시작되지 않기 때문이다 (AWS Kiro 공식 문서 2025.7; Kiro.dev 문서 2026).

OpenAI Codex: AGENTS.md + 조합형 Skills. 2025-2026년, AGENTS.md가 에코시스템의 중심으로 부상했다. Skills는 2026년 상반기의 핵심 확장 기능이다. “엑셀 읽기”, “SQL 생성”, “데이터 마이그레이션 실행” 같은 작업들을 미리 조립해 두고, 레고 블록처럼 호출하는 방식이다. Codex의 주간 활성 사용자는 2026년 6월 기준 500만 명을 돌파했으며, 그중 20%는 비개발자다. 이는 간과하기 쉬운 신호다. 규격 기반(Spec-driven) 접근은 더 이상 엔지니어링 팀만의 전유물이 아니라, 제품, 운영, 리스크 관리 등 전 구성원의 과제가 되었다는 뜻이다. 모두가 AGENTS.md를 작성하고 있다 (OpenAI 2026.6.2 공지; thebcms.com 리뷰 2026, 0.801 score).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic은 프로젝트 지침 문서를 CLAUDE.md(2026년 2월 공식 마켓플레이스 등록), .claude/rules/(디렉터리별 계층형 규칙), Skills(공유 가능한 워크플로우)로 구분한다. Claude Code는 2026년 상반기 개발자 만족도 1위 도구다 — JetBrains 2026.1 설문조사에서 CSAT 91%, NPS 54를 기록했고, 두 개의 독립 조사(Pragmatic Engineer 2026.2)에서도 동일한 결과가 나왔다. 이는 현재 AI 코딩 도구 시장에서 최고 점수다(uvik.net 2026.5, 0.956 score, 1차 소스 종합). Claude Code는 9개월 만에 연환산 매출 25억 달러를 돌파했고(2026.2 Anthropic G 라운드 기준), GitHub에서 11.2만 stars(Skills 저장소)를 확보했다 — 개발자들의 선택이 규칙 기반 접근의 실질적 가치를 증명하고 있다.

Alibaba Qoder: 중국 시장의 규제 주도형 접근. 2025년 8월에 처음 출시된 Qoder는 2026년 5월 15일 1.0 버전으로 업그레이드되면서, 기존의 ‘AI IDE’에서 ‘Autonomous Agent Development Workbench’로 공식적으로 재탄생했다. 이때 Spec-Driven Workflow도 함께 공개됐는데, Quest Mode(자율적 다중 파일 작업), Expert Mode(전문가 팀 병렬 작업), RepoWiki(저장소 지식 그래프)가 그 구성 요소다. 2026년 5월 28일에는 완전 관리형 에이전트 런타임인 Cloud Agents가, 7월 21일에는 규정 준수 및 보안 기능을 담은 Qoder Security가 출시됐고, 같은 달에 모바일 버전(Android/iOS/鸿蒙)도 선보였다. 2026년 5월 기준 전 세계 사용자 수는 500만 명을 돌파했으며, DingTalk CLI는 Qoder를 지원되는 에이전트 실행 환경 중 하나로 공식 등재했다(Yahoo Finance 2025; Alibaba Cloud 공식 자료 2026; Baidu Baike 2026.7).

공통 패러다임: “우리가 AI와 어떻게 협업할 것인가”를 명시적인 문서로 작성해 저장소(repository)에 넣고, 모든 사람과 모든 AI 에이전트가 동일한 규범을 기준으로 작업하게 하는 것. 다섯 개 플랫폼의 구현 세부 사항은 다르지만(파일명/단계 수/훅 메커니즘), 목표는 완전히 동일하다.

왜 이런 일이 2026년 상반기에 집중적으로 발생했을까? AI 역량의 문턱이 이미 지나갔기 때문이다. Claude Code의 자율 에이전트, Codex의 멀티 에이전트 병렬 처리, Cursor의 다중 파일 리팩토링까지, AI는 더 이상 “자동완성 도구”가 아니라 “동료”다. 새 동료에게 줄 온보딩 문서는 AI에게도 반드시 제공해야 한다.

3. 규범 주도는 도구 선택이 아닌 조직 역량이다

이것이 의사결정권자에게 가장 중요한 부분이다. 규범 주도는 도구를 선택하는 것이 아니라 “우리 조직이 AI와 어떻게 협업할지”를 정의하는 것이다. GitHub Spec Kit를 선택하든 Claude Code를 선택하든 중요하지 않다. 중요한 것은 규범을 문서로 작성해 저장소에 넣고, 모든 사람과 AI가 그 규범에 따라 작업하게 했는지 여부다.

이것이 없다면 아무리 좋은 도구라도 팀이 더 빠른 속도로 더 많은 기술 부채를 쌓게 할 뿐이다.

이 내용을 2026년 상반기 대규모 배포 관점에서 보면 근거가 더 확실해진다. Microsoft는 2026년 7월 FY26 회고록에서 EY와 Atos 사례를 “Frontier Firm” 템플릿으로 정리했다. 모델이 새로워서가 아니라, 두 기업 모두 “AI를 어떻게 쓸 것인가”라는 질문에 먼저 답을 했기 때문이다.

EY: 거버넌스 선행, 규모화로 성과 실현. EY는 2024~2025년에 Microsoft 365 Copilot을 15만 명에게 배포했고, 250만 시간과 약 2억 5천만 달러를 절감했다. 전제는 “AI 거버넌스 프레임워크를 먼저 구축”한 것이다. EY는 Power Platform, Copilot Studio, Azure, Foundry, Fabric을 활용해 통합 툴체인을 만들고, 규범·컴플라이언스·감사를 단일 기반 위에 올렸다. 그 덕분에 이후 95%의 속도 향상, 37%의 재무 운영 비용 절감, 최대 90%의 수작업 워크플로우 감소가 가능했다. EY 부사장은 2026 AI Tour에서 아주 직접적으로 말했다. “우리는 AI를 먼저 깔고 거버넌스를 나중에 보강한 게 아니다. 거버넌스를 먼저 갖추고 AI를 배포했다.”

Atos: 19,000개 에이전트를 위한 단일 제어 평면. Atos는 Microsoft 365 E7(Frontier Suite)을 도입한 세계 최초의 조직 중 하나로, 54개국 56,000명의 직원에게 Copilot을 배포했습니다. 현재 19,000개의 AI 에이전트를 동시에 운영 중이며, 내부 IT, 비즈니스 부서, 고객 프로젝트 전반에 걸쳐 Foundry와 Copilot Studio를 활용해 에이전트를 구축하고 있습니다. Atos가 이를 성공시킨 핵심은 “단일 제어 평면”입니다. Entra(아이덴티티) + Defender(보안) + Intune(디바이스) + Purview(컴플라이언스) + Agent 365(에이전트 거버넌스)라는 다섯 가지 요소를 하나로 묶은 구조입니다. 이러한 결합 방식은 금융 업계의 관점에서 보면 “ISMS-P 인증 + PIPA 국외이전 통지(PIPC 신고) + AI Basic Act 고위험 AI 등급 등록 + 감사 + 모델 거버넌스”에 해당하는, 단순한 AI 도구가 아닌 거버넌스 아키텍처입니다.

Microsoft의 ‘조직 변화 패러독스’. Microsoft는 2026 Work Trend Index 보고서에서 스스로 인정했습니다. **”조직 변화의 속도가 개인 사용을 따라가지 못하고 있다”**는 사실입니다. 이들이 조사한 20,000명의 AI 사용자 중 82%의 리더가 12~18개월 내에 AI 에이전트로 노동력을 확장할 계획이라고 답했지만, 실제로 기업 차원의 배포를 완료한 곳은 24%에 불과했습니다. 81%의 리더가 AI 에이전트가 AI 전략에 중간~대규모로 통합될 것이라고 예상했지만, 역시 실제로 실행에 옮긴 기업은 24%에 그쳤습니다. 즉, 대다수 기업이 ‘준비’와 ‘실행’ 사이에 12~18개월의 간극을 안고 있으며, 이 간극을 어떻게 메우느냐가 관건입니다. 그 중심에는 규범(governance) 주도 접근법이 자리잡고 있습니다.

출처: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, PDF 1차 소스); Futurum Group 2026.1.26 분석 (2차 소스).

시사점 1: 규범에 대한 투자는 ROI가 높다.

CodeRabbit의 데이터는 ROI 계산의 명확한 근거를 제시한다. AI 코드 문제 발생률이 약 1.7배, 보안 취약점이 2.74배 감소한다는 것이다. 이는 다음을 의미한다:

  • 더 적은 재작업(금융업에서 컴플라이언스 심사 재작업은 2~4주 소요)
  • 더 적은 보안 사고(데이터 유출 사고 시 규제 벌금, 평판 손실)
  • 더 낮은 유지보수 비용(기술 부채 40% 감소는 흔한 수치)

CLAUDE.md/AGENTS.md 프로젝트 규범을 작성하는 것은 AI 시대에 ROI가 가장 높은 엔지니어링 행동이다. EY의 사례는 실제 수치로 환산된 결과를 보여준다 — 15만 명에게 Copilot을 배포하여 2억 5천만 달러를 절감했다. 주목할 점은 EY가 “도구가 뛰어나서” 절감한 것이 아니라, “규범이 도구의 가치를 실제 성과로 전환시켰기 때문”이라는 것이다.

시사점 2: 규범을 개인 의존이 아닌 조직 프로세스로 내재화하라.

규범이 특정 시니어 엔지니어의 머릿속에만 존재하면, 인력이 이동하는 순간 사라진다. 반드시 다음에 체계화해야 한다:

  • 저장소 문서(AGENTS.md / CLAUDE.md / constitution.md)
  • CI 게이트(규범 준수 여부 자동 검증)
  • 팀 공유 설정(Skills 시스템을 통해 전 팀이 활용 가능)

규범을 개인의 스킬이 아닌 조직의 자산으로

이것은 금융 업계에서 특히 중요합니다——컴플라이언스 요구사항, 보안 규칙, 업무 규칙은 모두 조직 차원의 자산이지, 특정 엔지니어의 ‘경험’이 아닙니다. Atos의 19,000개 에이전트가 54개국에서 운영될 수 있는 이유는 거버넌스가 ‘누군가 알고 있는 것’이 아니라 ‘시스템이 강제하는 것’이기 때문입니다.

세 번째 교훈: 게이팅(gating)이 속도보다 중요하다.

GitHub Spec Kit의 5단계 게이팅(constitution → specify → plan → tasks → implement), Claude Code의 ‘테스트 실패 전에는 코드를 작성하지 않는다’는 원칙, Kiro의 ‘spec 없이는 시작 불가’ 정책——이 모든 것은 AI와 최종 산출물 사이에 ‘브레이크’를 설치하는 동일한 작업을 하고 있습니다. 각 단계마다 검토 가능한 산출물(spec.md, plan.md, tasks.md)이 존재하며, 코드 생성 전에 거부하거나 수정할 수 있습니다.

자율성이 높은 AI일수록 게이팅이 더 필요하다. 금융 업계의 변경 승인 위원회(Change Advisory Board, 변경 자문 위원회 (CAB)), AI Basic Act 고위험 AI 등급 등록 절차, ISMS-P 인증 평가(KISA 심사)는 본질적으로 프로덕션 배포 전에 게이팅을 추가하는 것입니다. AI 코드에도 유사한 게이팅이 필요하지만, 형태는 다를 뿐입니다. New Relic 2026 보고서에서 ‘자신 있게 검토 없이 배포한다’고 답한 62%의 팀은 더 높은 장애율(78%)로 이 같은 자신감에 대가를 치르고 있습니다.

금융 업계 규범 도입 3단계（2026 H1 실무 버전） 1단계: 규칙 정리 2-4주｜가장 시간 소요, ROI 최고 컴플라이언스 요구사항 체크리스트（등급보호/해외전송/신고） 보안 규칙（비밀번호/암호화/로그） 업무 규칙 (리스크 관리/거래/과금) 기술 제약 (기존 인터페이스/버전 제한) 공급업체 거버넌스 (계약/감사/책임) 여기저기 흩어진 규칙들을 구조화된 문서로 정리 2단계: 저장소에 반영 1-2주｜저장소에 넣고, AI 자동 로드 CLAUDE.md / AGENTS.md constitution.md Skills 정의 (공유 가능한 워크플로우) 게이트 프로세스 설계 (5단계) .claude/rules/ (계층형 규칙) 규칙을 저장소에 넣고, AI 자동 로드 3단계: 제도화 지속｜도구에서 조직 역량으로 CI 게이트 (자동 검토) 팀 공유 구성(Skills) 정기 업데이트 메커니즘(분기 검토) 측정(결함률/컴플라이언스 통과율) 에이전트 거버넌스(Agent 365 1급) 표준이 조직 자산이 되고, 개인에 의존하지 않음

1단계가 가장 시간이 걸리지만 ROI가 가장 높음
대부분 금융 조직의 규칙은 문서/이메일/머릿속에 흩어져 있으며, 첫 정리는 3-8주 투자

4. 2026년 상반기, 실제 도입을 위한 3단계 접근법

금융업을 기준으로 한 3단계 로드맵이며, 규제가 엄격한 다른 업종에서도 동일하게 적용할 수 있다. EY와 Atos가 2026년 상반기에 실제로 수행한 방식도 정확히 이 3단계와 맞아떨어진다.

1단계: 규칙 인벤토리 구축 (2~4주)

가장 시간이 걸리지만 ROI가 가장 높은 단계다. 여기저기 흩어져 있는 규칙들을 발굴한다:

  • 컴플라이언스 요건: 금융업의 최소 기준 = ISMS-P 인증(정보보호 및 개인정보보호 관리체계, KISA 심사) + PIPA 국외이전 통지(PIPC 신고 필요) + AI Basic Act 고위험 AI 등급 등록(2026.1 시행) (세 가지 중 하나라도 빠지면 AI 도입을 논할 수 없다). 여기에 더해 규제 보고 규칙, 고객 정보 보호, 데이터의 역외 이전 제한, AI에 어떤 데이터를 노출할 수 있는지에 대한 기준까지 포함된다.
  • 보안 규칙: 비밀번호 관리, 암호화 표준, 민감 필드 처리, 로그 요건
  • 비즈니스 규칙: 리스크 관리 임계값, 보험금 지급 조건, 거래 한도, 과금 로직
  • 기술 제약: 레거시 시스템 인터페이스, 데이터베이스 네이밍 규칙, 프레임워크 버전 제한
  • 공급업체 거버넌스: 계약서에 공급업체가 우리 표준을 따르도록 요구하는 방법, 공급업체의 AI 사용을 감사하는 방법

일반적인 시나리오: 한 증권사가 정리 단계에서 규칙이 수많은 Word 문서, JIRA wiki, 개인 이메일, Excel 표에 흩어져 있다는 것을 발견했다—정리한 후에야 구조화된 규칙 목록을 얻을 수 있었다. Atos의 접근 방식은 더 체계적이다—그들은 규칙을 “컴플라이언스, 보안, 비즈니스, 기술, 공급업체” 다섯 가지로 분류하고, 각각 하나의 거버넌스 워크플로우로 만들어 Agent 365의 컨트롤 플레인에 통합했다.

이것은 기술적인 작업이 아니라 조직적인 작업이다—컴플라이언스 부서, 보안 부서, 비즈니스 부서를 한자리에 모아 모두가 동의하는 규칙을 문서로 작성해야 한다. 처음 이 작업을 수행할 때 금융 조직은 보통 3-8주가 걸린다—하지만 이것은 영구적인 조직 자산이다.

2단계: 저장소에 반영 (1-2주).

1단계에서 정리한 규칙을 문서로 작성하여 저장소에 넣는다. GitHub Spec Kit는 constitution.md를 사용하고, Claude Code는 CLAUDE.md를, OpenAI Codex는 AGENTS.md를, Alibaba Qoder는 Spec Workflow를 사용한다. 파일 이름은 다르지만 목표는 동일하다—AI가 저장소를 여는 순간 규칙을 로드하도록 하는 것이다.

구조 제안 (2026 H1 기준 주류 형태)

  • 프로젝트 개요: 이 시스템이 무엇을 하는지, 누구를 위한 것인지
  • 불가침 원칙: 보안 레드라인, 컴플라이언스 레드라인, 비즈니스 레드라인
  • 기술 스택 및 제약 조건: 어떤 프레임워크, 어떤 데이터베이스, 어떤 인터페이스 규격을 사용하는지
  • 코드 규범: 네이밍 컨벤션, 디렉터리 구조, 테스트 최소 커버리지 요건 (TDD 리듬을 강제하지 않음 — 테스트 커버리지, 필수 테스트 경로, 금지 경로만 명확히 기술하면 됨. TDD는 조직이 선택할 수 있는 리듬이지, 규범으로 강제할 사항이 아님)
  • 비즈니스 규칙: 리스크 관리 로직, 거래 규칙, 과금 규칙
  • 컴플라이언스 요구사항: 정보보호 등급 평가, 데이터 해외 이전, 규제 보고, AI 생성 알고리즘의 사전 등록 필요 여부
  • AI 사용 규범: 어떤 시나리오에서 AI를 쓸 수 있고, 어떤 시나리오에서 반드시 사람의 검토가 필요한지, 데이터 해외 이전 규칙
  • 공급업체 거버넌스: 계약 조건, 감사 메커니즘, 책임 소재 구분

부록: CLAUDE.md 금융 버전 스켈레톤 (약 200줄, 바로 fork해서 커스터마이징 가능)

다음은 주식회사형 은행의 코어 시스템 개편을 위한 CLAUDE.md 스켈레톤으로, “불가침 원칙 → 컴플라이언스 요구사항 → AI 사용 규범 → 비즈니스 규칙 → 엔지니어링 제약 조건” 순서로 구성되어 있습니다. 여러분 회사는 처음부터 시작할 필요가 없습니다 — 빈 칸에 여러분의 구체적인 규칙만 채워 넣으면 됩니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
# CLAUDE.md — <시스템명> AI 협업 규범

> 적용 범위: <시스템명> v<버전>, 모든 AI 에이전트(Claude Code / Cursor / Copilot / Codex)
> 본 저장소에서 작업할 때 반드시 본 규범을 준수해야 합니다. 본 문서는 <거버넌스 위원회>에서 유지·관리하며, 분기별 심의를 거칩니다.
> 최종 업데이트: YYYY-MM-DD

## 1. 프로젝트 개요
- **업무 포지셔닝**: 코어 시스템명 / 서비스 고객군 / 주요 거래 유형
- **핵심 링크**: 거래 → 리스크 관리 → 청산 → 대사 → 보고
- **사용 불가 윈도우**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (어떤 변경도 진입 금지)
- **핵심 의존성**: 업스트림 <시스템>, 다운스트림 <시스템>, 규제 보고 플랫폼

## 2. 비협상 원칙 (레드라인, 위반 시 병합 거부)

### 2.1 보안 레드라인
- 비밀번호, 키, Token은 일률적으로 KMS(키 관리 서비스)를 경유, **하드코딩 금지**, **로그 인쇄 금지**
- 고객 민감 필드(신분증 / 카드번호 / CVV / 휴대폰번호) **반드시 암호화 저장**, 평문은 데이터베이스 저장 금지
- 로그에 등재 금지 항목: 완전한 신분증, 완전한 카드번호, 평문 비밀번호, 고객 이름+휴대폰번호 조합
- 외부 인터페이스 호출은 반드시 API 게이트웨이를 경유, 직접 연결 금지

### 2.2 컴플라이언스 레드라인
- AI 생성 코드가 고객 데이터 접근을 수반할 경우, 반드시 PR 설명에 "데이터 접근: <필드>" 명기
- 국경 간 데이터 전송 금지, **모든 데이터出境은 데이터出境 평가 프로세스(국경 간 데이터 전송 평가)를 거쳐야 함** (컴플라이언스 부서 연락)
- 알고리즘 의사결정(신용 대출 / 보험 가격 산정 / 부정 결제 방지)은 반드시人工复核(인간 재검토) 입구 유지
- 모델 변경은 알고리즘 등록(알고리즘 등록) 절차를 거쳐야 하며, 등록 번호는 반드시 PR 설명에 인용

### 2.3 업무 레드라인
- 리스크 관리 임계값 변경은 리스크 관리 책임자 + 업무 책임자 이중 서명 필요
- 고객 자금 관련 작업은 반드시 멱등성 설계 + 실패 롤백 필수
- 거래 한도, 요율, 제품 파라미터 변경은 파라미터 관리 플랫폼을 거치며, 코드 내 하드코딩 금지

## 3. 기술 스택 및 제약
- **언어**: Java 17(코어) / Kotlin(신규 모듈) / SQL(데이터베이스)
- **프레임워크**: Spring Boot 3.x + Spring Cloud Alibaba
- **데이터베이스**: OceanBase 4.x(MySQL 호환 모드), **외래 키 사용 금지**
- **인터페이스 규범**: 내부 일률적으로 gRPC; 외부 인터페이스 OpenAPI 3.0; RESTful은 관리 클래스 인터페이스에 한정
- **명명 규약**: Java 클래스 PascalCase, 메서드 camelCase, 상수 UPPER_SNAKE; 테이블명 `t_<업무 도메인>_<엔티티>`; 인덱스 `idx_<테이블>_<필드>_<순서>`
- **패키지 구조**: `com.<회사>.<업무 도메인>.<서브 도메인>.<레이어>` (예: `com.bank.pay.tx.core.service`)

## 4. 코드 표준
- **최소 테스트 커버리지**: 핵심 링크 ≥ 80%, 유틸리티 클래스 ≥ 60%, 신규 코드 PR은 반드시 테스트 포함
- **필수 테스트 경로**: 모든 controller는 반드시 통합 테스트 필요(실패 경로 포함); 모든 enum 분기는 반드시 단위 테스트 필요
- **금지 경로**: `<역사包袱 모듈>` 디렉터리 수정 금지 — 먼저 어댑터 레이어 구축 필요
- **의존성 관리**: 신규 제3자 의존성은 SCA 스캔 + 보안 승인 필수

## 5. 업무 규칙 (도메인별)
### 5.1 거래
- 1회 한도: <금액>; 1일 한도: <금액>; 한도 초과 시人工 승인 필요
- 거래 시간 윈도우: <HH:MM> ~ <HH:MM>
- 중복 거래 판정: <시간 윈도우> 내 동일 <필드>는 중복으로 간주

### 5.2 리스크 관리
- 블랙리스트 매칭 우선순위: 내부 블랙리스트 → 규제 하달 명단 → 사법 동결
- 부정 결제 방지 모델 출력 임계값: <점수>; 초과 시 반드시人工 이차 심사 필요

### 5.3 과금
- 요율 변경은 반드시 버전 번호 +生效 시간(발효 시간) 필요
- 과거 주문은 발효 시점의 요율로 계산, 소급 적용 안 함

## 6. 컴플라이언스 요구사항
- 등보三级(MLPS 레벨 3): <평가 기관>, <차기 평가 일자>
- 데이터出境 평가(국경 간 데이터 전송 평가): 적용 범위(국경 간 업무 모듈에 한정)
- 알고리즘 등록(알고리즘 등록): 적용 범위(신용 대출 / 보험 가격 산정 등 핵심 알고리즘), 등록 번호 `<번호>`
- 규제 보고(규제 보고): <CBIRC / 중국 인민은행> 필드 매핑 테이블은 `<경로>`에 위치

## 7. AI 사용 규범
- **AI 사용 가능 시나리오**: CRUD 보일러플레이트, 단위 테스트 생성, 문서 초안, SQL 최적화 제안
- **人工 심사 필수 시나리오**: 리스크 관리 로직, 과금 규칙, 권한 제어, 암복호화, 국경 간 데이터
- **AI 단독 수행 금지 시나리오**: 변경 자문 위원회 (CAB)(변경 자문 위원회) 심사 자료, 생산 변경 실행, 응급 대응
- **데이터出境 규칙**: 학습 데이터 / 프롬프트 / 출력 로그 일체出境 불가; 현지화 배포 버전(<벤더>) 우선
- **감사 요구사항**: 모든 AI 생성 코드는 PR 설명에 "AI 보조: <도구명>" 표시 필수

## 8. 공급업체 거버넌스
- **공급업체 진입**: SOC 2 / ISO 27001 보고서 제공 필수; AI 모델은 모델 카드 제공 필수
- **계약 조항**: 데이터 귀속, 모델 해석 가능성, 탈퇴 조항, 감사권
- **감사 메커니즘**: 분기별 공급업체 AI 사용 감사; 고위험 공급업체는 월간 감사

## 9. 거버넌스 및 업데이트
- **소유자**: <거버넌스 위원회>(컴플라이언스 + 보안 + 아키텍처 + 업무)
- **업데이트 빈도**: 분기 심의; 긴급 변경은快速 통로(双签 + 24h 공시) 경유
- **변경 로그**: `CLAUDE_CHANGELOG.md` 참조
- **위반 처리**: 첫 위반 = 경고 +强制培训(강제 교육); 2차 위반 = AI 도구 사용 정지; 3차 = 권한 취소

이 뼈대는 “정답”이 아니라 “빈칸 채우기 템플릿”입니다. 각 빈칸에 무엇을 넣을지가 분량보다 중요합니다——빈칸이 드러내는 것은, 바로 우리 회사가 “아직 제대로 정리하지 못한” 부분입니다.

전형적인 사례: 한 주식회사형 은행(중국 상업은행)의 CLAUDE.md에는 비밀번호 처리 규칙이 명시되어 있습니다——AI가 생성한 코드에 비밀번호가 포함될 경우 반드시 내부 키 관리 API를 호출해야 하며, 하드코딩을 금지합니다. 이런 유형의 규칙은 컴플라이언스 심사에서 반려되는 사유 중 상당한 비중을 차지합니다.

2026년 상반기의 중요한 새 필드는 Skills/워크플로 정의입니다——단순한 문서가 아니라, AI가 호출할 수 있는 도구 체인입니다. Claude Code의 Skills 시스템(2026년 2월 Anthropic 공식 마켓에 등록, GitHub 11.2만 stars)은 “Excel 읽기”, “SQL 생성”, “데이터 마이그레이션 실행” 같은 작업들을 공유 가능한 워크플로로 전환합니다. 이것이 2026년 상반기 규범 기반 접근법의 핵심 진화입니다: 규범은 단순한 제약이 아니라, 실행 가능한 워크플로입니다.

3단계: 제도화(지속).

规范 작성이 끝이 아니라 시작이다. 이를 조직의 프로세스로 만들어야 한다:

  • CI 게이트 통합: 코드가 규범을 준수하는지 자동 검사(예: 하드코딩된 비밀번호, 민감 필드 미암호화 탐지)
  • 팀 공유 설정: Skills 시스템을 활용해 전 팀이 동일한 규범을 사용
  • 정기 업데이트 메커니즘: 규칙이 바뀌면 규범도 따라 바뀌어야 함(분기별 검토)
  • 측정 및 피드백: AI 코드의 결함률, 컴플라이언스 심사 통과율, 재작업률 추적
  • 에이전트 거버넌스: 사람에 대한 거버넌스를 AI 에이전트로 확장 — Atos가 Agent 365에서 한 것은 이를 “개인 수준”이 아닌 “시스템 수준”으로 만든 것이다

EY와 Atos는 2026년 상반기에 모두 3단계를 “조직 역량”으로 규정했다. EY의 250만 시간 절감은 1단계와 3단계를 제대로 수행했기 때문이다 — 2단계는 단지 규칙을 AI가 읽을 수 있는 문서로 번역한 것에 불과하다.

5. 강규제 변형: 컴플라이언스를 내장하는 세 가지 엔지니어링 방식

금융, 통신, 의료 등 강규제 산업에서는 규범 기반 도입이 일반 산업보다 한 단계 더 까다롭다 — 컴플라이언스는 프로세스의 부가 기능이 아니라 코드에 내장되어야 한다. 아래 세 가지 방식은 2026년 상반기에 검증된 컴플라이언스 내장 방법으로, CIO/디지털 책임자가 조직 설계 시 바로 참고할 수 있다.

5.1 스트림 팀 내 컴플라이언스 담당자 임베드: ‘사후 승인’이 아닌 ‘현장 상주’로

기존 방식은 비즈니스 팀이 코드를 작성하고 컴플라이언스 팀이 사후에 검토하는 구조였다. 문제는 검토에서 이슈가 발견됐을 때 이미 코드가 배포된 지 2주가 지났고, 재작업에 2~4주가 추가로 소요된다는 점이다. 핵심 문제는 컴플라이언스가 프로세스의 맨 끝에 위치한다는 것이다.

새로운 접근법은 각 스트림 정렬 팀(stream-aligned team)에 컴플라이언스 담당자를 상주시키는 것이다. 보고 체계는 ‘실선은 컴플라이언스 부서, 점선은 비즈니스 팀’으로 하는 이중 보고 구조를 따른다. 구체적인 설계는 다음과 같다.

  • 인력 배치: 컴플라이언스 담당자 1명당 스트림 팀 6~8개를 담당한다. 소속은 컴플라이언스 부서이되, 물리적 자리는 비즈니스 팀에 둔다. 출장식 ‘파견’이 아니라 상주가 원칙이다.
  • 점선 KPI: 컴플라이언스 담당자의 KPI 중 50%는 비즈니스 팀의 ‘컴플라이언스 결함률’과 ‘검토 1회 통과율’에 연동된다. 단순히 컴플라이언스 부서의 ‘감사 커버리지’만 보는 것이 아니다.
  • 조기 개입: 컴플라이언스 담당자는 데일리 스탠드업(주 1회면 충분), PR 검토에 참여하며, AI가 생성한 코드는 병합(merge) 전에 반드시 컴플라이언스 담당자의 확인을 거쳐야 한다. 병합 후에 문제가 발견되어 뒤늦게 보완하는 구조가 아니다.
  • 도구 지원: 컴플라이언스 담당자는 컴플라이언스 체크리스트를 Skills로 호출해 활용하며, 수작업으로 항목을 일일이 대조하지 않는다.

5.2 컴플라이언스를 enabling team으로: 제약을 affordance로 바꾸기

전통적인 방식에서는 컴플라이언스 팀이 ‘게이트키퍼’ 역할을 하고, 비즈니스 팀은 컴플라이언스를 ‘문제를 만드는 존재’로 여긴다. 양측은 제로섬 게임을 하게 된다.

새로운 접근법은 이렇다. 컴플라이언스 팀을 Team Topologies의 enabling team 모델로 재구성하는 것이다. 코드를 직접 작성하지도 않고, PR을 직접 리뷰하지도 않지만, 비즈니스 팀이 ‘셀프 컴플라이언스’를 할 수 있도록 세 가지를 제공한다.

5.3 이중 속도 컴플라이언스: 비즈니스 템포에 맞춘 계층화 전략

  1. CI 파이프라인 내 컴플라이언스 게이트: 하드코딩된 비밀번호, 민감 필드 평문 저장,跨境 데이터 전송, 알고리즘 의사결정 지점 등 고빈도 컴플라이언스 이슈를 GitHub Actions / GitLab CI의 강제 게이트로 구현한다. 비즈니스 팀의 PR이 트리거되면 자동 검사가 실행되고, 미준수 시 즉시 fail 처리된다 — 컴플라이언스 담당자가 수동으로 검토할 필요가 없다.

  2. 규제 요구사항을 affordance(환경 반응형 제약)로 전환: 예를 들어, 고객 데이터를 다루는 기능을 개발할 때 IDE 플러그인이 “이 필드는 KMS 호출을 권장합니다”라는 힌트를 띄우고, 로그 작성 시 민감 정보 포함 여부를 자동 감지하여 경고를 발생시킨다. 컴플라이언스 요구사항이 “개발 중 자연스럽게 발생하는 동작”이 되는 것이지, “배포 직전에 무엇을 위반했는지 통보받는 것”이 아니다.

  3. 공유 Skills 라이브러리 + 컴플라이언스 교육: 컴플라이언스 팀이 “컴플라이언스 Skills” 집합을 유지 관리하고, 신규 입사자나 크로스 팀 전환 시 바로 활용할 수 있게 한다 — 컴플라이언스 지식을 “문서”에서 “실행 가능한 도구”로 전환하는 것이다.

대표 사례: 한 지방은행이 2026년 상반기에 CI 컴플라이언스 게이트 + IDE 컴플라이언스 힌트를 도입하여, AI 코드 컴플라이언스 검토의 1인당 소요 시간을 건당 45분에서 8분으로 단축했다. **핵심은 컴플라이언스 “검토가 빨라진 것”이 아니라, AI가 생성할 때부터 “실수를 하지 않는 것”**이다.

마지막으로 짚을 디테일 하나: 컴플라이언스를 “무조건 일괄 적용”하면 안 된다. 규칙을 위험 등급에 따라 두 단계로 나누자.

  • 고위험 규칙(고객 자금 / 알고리즘 의사결정 / 역외 데이터 이동 / ISMS-P 인증 + PIPA 국외이전 통지 기준)은 엄격한 게이트를 적용한다: 반드시 인간 검토 + AI 2차 확인 + 변경 자문 위원회 (CAB)(Change Advisory Board) 등록
  • 저위험 규칙(CRUD 템플릿 / 도구성 코드 / 문서 생성)은 셀프서비스 게이트를 적용한다: CI 자동 검사만으로 충분, 인간 검토 불필요

Atos의 Agent 365 컨트롤 플레인도 본질적으로 이렇게 계층화되어 있다 — 에이전트 등급에 따라 서로 다른 거버넌스 요구사항을 바인딩한다. 컴플라이언스 규칙을 위험도에 따라 계층화하면, 비즈니스 팀이 “컴플라이언스가 우리를 여기저기서 옥죄는구나”라는 느낌을 덜 받게 된다.

이 세 가지를 종합하면: 컴플라이언스 임베딩은 단순히 프로세스 하나를 추가하는 것이 아니라, 팀의 구조와 인센티브를 재설계하는 일이다. 컴플라이언스 부서가 여전히 “사후 심사” 모드에 머물러 있다면, 규범 기반 적용은 가장 어려운 “제도화” 단계에서 막힐 수밖에 없다 — 컴플라이언스 부서가 먼저 전환해야, 비즈니스 팀의 규범 기반 적용이 순조롭게 돌아간다.

6. 궁금할 법한 질문들

“우리도 이미 코딩 규범이 있는데, 이거랑 뭐가 다른가요?”

코딩 규범은 “코드를 어떻게 작성할지”를 다루고, 규범 기반 적용은 “AI와 어떻게 협업할지”를 다룬다. 코딩 규범에는 다음이 포함되지 않는다: 비즈니스 규칙, 컴플라이언스 요구사항, AI 사용 전략. 규범 기반 적용은 “인간과 AI의 협업 전체 프로세스”를 명시화하는 것이지, 코드 스타일 가이드가 아니다.

“규범을 작성하면 개발 속도가 떨어지지 않나요?”

단기적으로는 그렇습니다. 하지만 장기적으로는 오히려 빨라집니다. CodeRabbit의 데이터가 명확한 답을 줍니다. 제약 없는 AI 코드는 결함 위험이 약 1.7배, 보안 취약점 위험이 2.74배 높습니다. 금융 업계에서 컴플라이언스 심사 한 번에 따른 재작업은 2~4주가 걸립니다. 재작업 한 번을 줄이면 한 달 치 규범을 작성할 시간이 생깁니다. EY가 2억 5천만 달러를 절감한 사례는 이걸 조직 역량으로 만든 실제 증거입니다.

“우리 팀에 규범을 작성할 사람이 없으면 어떻게 하나요?”

처음부터 시작할 필요가 없습니다. GitHub Spec Kit, Claude Code Superpowers, AWS Kiro에는 이미 템플릿이 있습니다. 조직 고유의 규칙만 채워 넣으면 됩니다. 대부분은 컴플라이언스와 보안 규칙인데, 이런 건 규정 준수 부서와 보안 부서가 이미 작성해 두었습니다. 단지 AI가 접근할 수 있는 곳에 두지 않았을 뿐입니다.

“AI 도구가 너무 많은데 어떤 걸 선택해야 하나요?”

중요하지 않습니다. 이미 쓰고 있는 걸 선택하세요. 규범 중심이라 도구에 얽매일 필요가 없습니다. CLAUDE.md는 Claude Code, Cursor, Codex에서 모두 동작하고, AGENTS.md는 OpenAI 생태계에서 실행되며, constitution.md는 모델과 무관합니다. 핵심은 도구를 바꾸는 게 아니라 규범을 작성하는 겁니다. EY도 Atos도 Microsoft 생태계에서 확산하고 있습니다. 도구 선택의 차이는 표면적일 뿐이고, 거버넌스 구조의 통일성이야말로 본질입니다.

“2026년 8월에 EU AI Act가 전면 시행되는데, 우리에게도 영향이 있을까요?”

있습니다. EU AI Act는 2026년 8월 2일부터 전면 시행 단계에 돌입하며, 고위험 AI 시스템(신용·보험 가격 산정, 채용 심사, 핵심 인프라 포함)에 대해 강제적 준수 요건을 부과합니다 — 위험 관리(Art. 9), 데이터 거버넌스(Art. 10), 문서 투명성(Art. 11–13), 인간 감독(Art. 14), 정확성·견고성(Art. 15)이 그것입니다. 위반 시 과징금은 최대 3,500만 유로 또는 글로벌 매출의 7%에 달합니다. 중국에서 해외로 진출하는 기업에게 EU 시장은 반드시 풀어야 할 과제이고, 국내 기업에게도 EU AI Act의 프레임워크는 전 세계에서 가장 많이 참조되는 기준입니다. 직접 적용 대상이 아니더라도 공급업체, 파트너, 해외 사업을 통해 전이되는 영향(transmission effect)을 피해가기는 어렵습니다 (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

“국내 대조: EU는 AI를 규제하는데, 우리는 무엇을 규제하나?”

국내의 생성형 AI 규제는 ‘알고리즘 등록 + 말뭉치 검토 + 안전성 평가’라는 세 가지 축으로 운영되며, 2023년 8월 시행된 《생성형 인공지능 서비스 관리 잠정 조치》가 핵심 근거입니다. 양측의 가장 큰 차이는 조문의 세밀함이 아니라 입법 철학에 있습니다.

차원EU AI Act중국 <생성형 AI 서비스 관리 방법>
법적 성격수평 규제(모든 AI 시스템에 적용)수직 규칙(생성형 AI 서비스에 초점)
위험 등급4단계(허용 불가 / 고위험 / 제한적 / 최소)2단계(여론 안전 관련 / 일반 상업용)
규제 시점사전 규제(개발 단계에서 등록)사후 규제(서비스 출시 후 등록 + 알고리즘 등록)
투명성높음(학습 데이터 출처 요약, 모델 카드 공개 의무)중간(데이터 컴플라이언스 요구하되 출처 공개는 강제하지 않음)
벌칙 상한글로벌 매출의 7% 또는 3,500만 유로서비스 중단 / 벌금(일반적으로 위법 소득의 배수)
적용 범위글로벌 매출 기준을 충족하는 모든 기업중국 내에서 서비스를 제공하는 모든 주체

실무적으로 국내 금융기관의 AI 시스템은 대개 세 가지 규제 체계를 동시에 적용받는다—— 「AI Basic Act(인공지능기본법, 2026.1 시행)」(기반 계층) + 「상업은행 인터넷 대출 관리 잠정 조치」(업무 계층) + 「ISMS-P 인증 + PIPA 국외이전 통지 + PIPC 신고」(컴플라이언스 계층). 이는 국내에서 규범 기반 개발을 할 때 EU AI Act의 프레임워크를 그대로 가져올 수 없음을 의미한다. 국내의 “코퍼스 컴플라이언스 + 알고리즘 등록 + 규제 보고”라는 세 가지 축을 전부 CLAUDE.md에 반영해야 한다.

해외 진출 기업의 관점에서 보면: EU AI Act의 “위험 관리 + 데이터 거버넌스 + 문서 투명성 + 인간 감독”이라는 네 가지 축은 중국 규제도 점진적으로 정렬하고 있는 방향이다——2025년 중국 인터넷정보판공실(CAC)의 생성형 AI 등록 피드백을 보면 이미 EU 수준의 세분화(granularity)를 상당 부분 참조했다. 오늘 EU AI Act 호환 규범을 작성해 두면, 향후 3년간 중국의 규제 강화 기조와도 대체로 호환될 가능성이 높다(CAC 등록 공고 2025-2026; EU AI Act compliance 2026.6).

7. 의사결정자를 위한 시사점

시사점 1: CLAUDE.md/AGENTS.md 프로젝트 규범을 작성하는 것은 AI 시대에 ROI가 가장 높은 엔지니어링 조치다.

교훈 2: 규범 주도는 조직 역량이지, 도구 선택의 문제가 아니다.

GitHub Spec Kit을 쓰든 Claude Code를 쓰든 중요한 건 아니다. 중요한 건 “우리 조직이 AI와 어떻게 협업할 것인가”를 정의했는지다. 이게 없으면 아무리 좋은 도구도 팀이 더 빠른 속도로 더 많은 기술 부채를 쌓게 만들 뿐이다.

교훈 3: 규범을 개인에게 의존하지 말고 조직 프로세스로 제도화하라.

규범이 시니어 엔지니어 한 명의 머릿속에만 존재하면, 인력이 이동하는 순간 사라진다. 반드시 리포지토리 문서, CI 게이트, 팀 공유 설정, 에이전트 거버넌스 플랫폼에 체화시켜야 한다. 규범을 개인의 스킬이 아닌 조직의 자산으로 만들어라. Atos의 19,000개 에이전트가 54개국에서 문제없이 작동하는 이유는 거버넌스가 “누군가 알고 있는 것”이 아니라 “시스템이 강제하는 것”이기 때문이다.

교훈 4: 속도보다 게이트가 우선이다.

GitHub Spec Kit의 5단계 게이트(gate), Superpowers의 “테스트가 실패하기 전에는 코드를 쓰지 않는다”는 원칙, Kiro의 “스펙 없이는 시작할 수 없다”는 규칙 — 이 모든 것은 AI와 최종 산출물 사이에 ‘브레이크’를 걸어두는 장치다. AI의 역량이 강해질수록 거버넌스가 더 앞서야 한다. New Relic 2026 보고서의 78% 장애율은, 62%의 팀이 “검토 없이 배포”한 대가다. 금융 업계의 CIO라면 이걸 가장 잘 이해할 것이다. 여러분의 변경 자문 위원회(Change Advisory Board), AI Basic Act 고위험 AI 등급 등록 절차, ISMS-P 인증(KISA 심사) 평가는 모두 프로덕션 배포 전에 게이트를 거는 장치다. AI 코드에도 동일한 게이트가 필요하며, 더욱이 더 앞단에 배치되어야 한다.

역방향 자가 점검(미화하지 말 것): AI가 생성한 코드에 대한 컴플라이언스 검토가 자주 반복되고 있는가? 최근 AI 코드로 인해 발생한 장애는 무엇인가? 기술 책임자에게 “우리는 AI와 어떻게 협업하는가”라고 물었을 때, 그가 문서 하나를 꺼내 보여줄 수 있는가? 세 가지 중 하나라도 답이 막힌다면, 규범 주도 개발이 아직 정착되지 않았다는 뜻이다 — 규범을 먼저 쓰고, 그다음 도구를 도입하라.

의사결정자를 위한 세 가지 코칭 질문

마지막으로 세 가지 질문을 남긴다. 체크리스트가 아니라, 팀과 논의할 때 바로 활용할 수 있는 질문이다.

  1. “만약 내일 모든 AI 도구가 사라진다면, 우리 팀의 코드 품질은 얼마나 떨어질까?” — 이 질문이 드러내는 것은 규범 기반 접근법의 실제 가치입니다. 만약 답이 “크게 떨어진다”라면, 아직 규범이 팀에 제대로 내재화되지 않았다는 뜻입니다. 반대로 “거의 변함없다”면, 규범 기반 개발이 이미 자리 잡았다는 방증입니다.
  2. “컴플라이언스 부서는 우리의 규범 기반 프로젝트에서 ‘게이트키퍼’인가, 아니면 ‘조력자(enabler)’인가?” — “게이트키퍼”라는 답이 나온다면, 검토 병목으로 인해 실행 속도가 막히게 됩니다. “조력자”라는 답이 나온다면, 5.2절에서 제시한 방향으로 이미 올바르게 나아가고 있는 것입니다.
  3. “12~18개월 후, 우리 팀 규모는 어떻게 변할까?” — Microsoft WTI 2026 보고서에 따르면, 리더의 82%가 AI 에이전트를 통해 인력을 ‘확장’할 것이라고 답했습니다. 만약 “변함없다”는 답이 나온다면, 사업이 성장하지 않고 있거나, 조직 설계가 규범 기반 접근법이 가져다주는 이점을 따라가지 못하고 있다는 신호입니다.

이 세 가지 질문에 정답은 없습니다. 하지만 답의 방향성은 답 자체보다 더 중요합니다.

다음 단계

이 글은 “AI 시대 소프트웨어 엔지니어링의 변화” 시리즈의 여섯 번째 편입니다. Conway의 법칙(조직이 아키텍처를 결정한다)에서 시작해 Team Topologies(조직을 어떻게 설계할 것인가), 병목의 이동(병목은 코딩이 아닌 검증에 있다)을 거쳐, 오늘은 규범 기반 접근법(문서로 AI의 행동을 제약하기)까지 다루었습니다.

다음 편(일곱 번째)에서는 이 모든 것을 뒷받침하는 기반 인프라——**MCP 프로토콜(Model Context Protocol)**을 살펴봅니다. Anthropic이 오픈소스로 공개한 이 프로토콜이 왜 “AI의 USB-C”라고 불리는지, OpenAI·Google·Microsoft가 왜 모두 동참했는지, 그리고 이 프로토콜이 어떻게 다중 도구·다중 에이전트 간 상호운용성을 가능하게 하는지 다룹니다.

이 판단 체계를 실제로 도입하려면?

규범 기반 개발이 기업에 들어오면 실제로 풀어야 할 문제는 대개 몇 가지로 좁혀집니다. 핵심 규칙을 CLAUDE.md / AGENTS.md로 어떻게 정형화할 것인지, 기존 코드에 규범을 어떻게 보강할 것인지, 컴플라이언스 임베딩을 어떻게 설계할 것인지, 그리고 파일럿을 어떤 지표로 검증할 것인지가 그것입니다.

현재 세 가지 형태로 협업을 제공합니다.

  • 기업 내 교육(Enterprise Training): 고객사의 실제 프로젝트를 기반으로 규범 문서 정리, CI 게이트 설계, 컴플라이언스 임베딩 경로, 거버넌스 체계 구축까지 완결합니다.
  • 전문 자문(Advisory): “우리 회사가 먼저 CLAUDE.md / AGENTS.md를 작성해야 하는가” 또는 기존 코드의 컴플라이언스 개선 우선순위 같은 명확한 의사결정 하나에 집중합니다.
  • 경영진 세미나 및 산업 강연: AI 코딩 도구, 규범 기반 개발, 조직 거버넌스, Frontier Firms를 주제로 진행합니다.

이 글은 일반적인 프레임워크를 제시하지만, 실제 도입은 기업의 컴플라이언스 요건, 규제 경계, 엔지니어링 성숙도, 기존 딜리버리 프로세스를 고려해 재설계해야 합니다. 협업 문의는 coach@iaiuse.com으로 연락 주시기 바랍니다.

추가 자료: 《간판 방법론 v1.0》(천천히 배우는 AI 187) — 기업 AI 전환을 위한 7단계 프레임워크를 체계적으로 소개합니다.

시리즈 소개

“AI 시대 소프트웨어 엔지니어링 혁신”은 통신, 금융, 제조, 이커머스 업계의 CIO, CDO, CTO 및 디지털 전환 책임자를 대상으로 한 연구 시리즈로, 총 18편으로 구성되어 있습니다. AI 코딩 도구, 규범 기반 개발, 조직 거버넌스가 소프트웨어 딜리버리 프로세스, 조직 구조, 엔지니어링 성숙도에 어떤 영향을 미치는지 중점적으로 다룹니다.

이 시리즈는 학술 논문, 벤더 자료, 업계 보고서를 지속적으로 추적하며, 연구 자료는 누적 200건 이상입니다. 주요 판단에는 근거 수준을 표기하여 검증된 사실, 벤더 주장, 업계 관찰, 저자 추론을 최대한 구분하려 했습니다.

저는 대기업 컨설팅 및 비즈니스 분석 분야에서 약 8년간 근무했으며, IBM 재직 시절 통신, 금융, 보험, 제조 프로젝트에 참여한 바 있습니다. 이후 통신사 프로덕트, 인터넷 프로덕트, AI 애플리케이션 개발 현장에서 요구사항 분석, 제품 설계, 크로스 팀 협업을 주도해 왔습니다.

참고 출처 (모두 검증 완료, 항목별 증거 수준 표기)

본 시리즈의 규범 주도, 조직 거버넌스, 엔지니어링 관점에서의 판단은 이러한 실무 경험을 바탕으로 하되, 공개 연구 및 업계 사례와 교차 검증을 거쳤습니다. 특정 프로젝트와 관련된 내용은 모두 비식별화되었으며, 일부 업계 시나리오는 전형적인 문제를 추론한 사례이므로 관련 근거는 본문 말미의 참고 출처를 참조하시기 바랍니다.

이 블로그는 사실 소규모 팀이 운영하고 있습니다. 저와 1-2명의 장기 협업 동료가 각각 AI 코딩 도구 연구, 조직 거버넌스 사례 정리, 코칭 대화 분야를 나누어 담당하고 있습니다. 본문에서 “우리가 기업과 함께 헤쳐 나온” 프로젝트의 대부분은 저희가 공동으로 수행한 것입니다. 고객의 컴플라이언스 경계와 개인 정보는 여전히 공개하지 않으며, 익명성은 향후 협업할 동료들을 위해 유지합니다.

참고 출처 (모두 검증 완료, 항목별 증거 수준 표기)

  • CodeRabbit (2025.12). State of AI vs Human Code Generation Report. AI가 생성한 코드의 문제 발생률이 인간 개발자 대비 1.7배(PR당 10.83건 vs 6.45건)로 나타났다. 세부적으로 로직/정확성 1.75배, 코드 품질 1.64배, 보안 1.57배, 비밀번호 처리 1.88배, XSS 2.74배로 집계됐다. 근거 수준: 1차. 출처: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263

  • The Register (2025.12.17). CodeRabbit 보고서 전문 보도: 오픈소스 PR 470건을 분석한 결과, AI 협업 PR에는 평균 10.83건의 문제가 발견된 반면 순수 인간 개발 PR에는 6.45건에 그쳤다. 근거 수준: 2차. 출처: 위와 동일한 URL

  • CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap” — 2026년은 ‘코드 생성 속도’에서 ‘코드 품질과 거버넌스’로 초점이 이동하는 전환점이 될 것이다. 증거 수준: 2차. 출처: https://tfir.io/ai-code-quality-2026-guardrails

  • New Relic (2026). The 2026 State of AI Coding Report. 팀의 78%가 AI 코드 배포 이후 장애가 더 빈번해졌다고 응답했으며, 62%의 기술 리더는 팀이 “자신감 있게 검토 없이 배포”하는 상황을 인정했다. 96%는 옵저버빌리티가 필수라고 답했다. 증거 수준: 1차(벤더 보고서). 출처: https://newrelic.com/resources/report/2026-state-of-ai-coding

  • Microsoft 2026 Work Trend Index 연례 보고서 (2026.5.5). AI 작업자 20,000명 대상 조사, 10개국 포함. 리더의 82%가 1218개월 내 AI 에이전트로 인력 확장을 계획 중이며, 81%는 AI 에이전트가 중간대규모로 통합될 것으로 예상. 24%는 이미 엔터프라이즈 수준에서 배포 완료. Copilot 대화의 49%가 인지 업무를 지원하며, AI 사용자의 58%가 “1년 전에는 불가능했던 일”을 해내고 있고, Frontier Professionals의 경우 이 비율이 80%까지 상승. 근거 수준: 1급. 출처: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf

  • Microsoft FY26 회고: AI 실험에서 프런티어 트랜스포메이션으로 (2026.7.28). EY는 Microsoft 365 Copilot을 150,000명의 임직원에게 배포하여 250만 시간, 약 2억 5천만 달러를 절감했습니다. 이후 40만 글로벌 임직원으로 확장하여 업무 속도 95% 향상, 재무 운영 비용 37% 절감, 최대 90%의 수작업 워크플로우 감소를 달성했습니다. Atos는 Copilot을 56개국 56,000명의 임직원과 19,000개의 AI 에이전트에 배포하고, 통합 ID/보안/컴플라이언스/거버넌스 컨트롤 플레인을 구축했습니다. 근거 수준: 1급(마이크로소프트 공식 회고). 출처: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Atos Group와 Microsoft의 전략적 협업 (2026.6.9). Atos는 56개국 56,000명의 임직원과 19,000개의 AI 에이전트에 Microsoft 365 E7(Frontier Suite)을 배포했습니다. Entra/Defender/Intune/Purview/Agent 365 제어 플레인을 단일화했습니다. 근거 수준: 1급(양사 공동 보도자료). 출처: 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 (2025.9 오픈소스 공개, 2026년 상반기까지 지속 진화 중). 5단계 게이트 방식 /speckit.constitution → /specify → /plan → /tasks → /implement에 /clarify /analyze을 결합하며, 모델에 구애받지 않는다는 점이 특징입니다. Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / — 모두에서 동일하게 활용됩니다. 증거 수준: 1급(최상위 신뢰도). 출처: https://github.com/github/spec-kit

  • AWS Kiro (2025.7 출시, 2026년 상반기까지 진화 중). 3단계 워크플로우(요구사항 정의 → 설계 → 태스크 분해 및 실행)를 채택하며, spec이 미리 정의된 에이전트 동작을 트리거합니다. 즉 spec을 작성하지 않으면 프로젝트를 시작할 수 없습니다. 증거 수준: 1급(최상위 신뢰도). 출처: https://kiro.dev/ (역자 주: 현재는 AWS Kiro 공식 페이지로 리다이렉트됨)

  • OpenAI Codex + AGENTS.md + Skills (2025-2026). Codex는 2026년 6월 기준 주간 활성 사용자 500만 명을 돌파했으며, 이 중 비개발자가 20%를 차지한다. AGENTS.md와 Skills는 조합 가능한 명령어 집합을 제공한다. 근거 등급: 1급(OpenAI 공식 발표). 출처: https://developers.openai.com/codex/skills

  • Claude Code (Anthropic, 2026 상반기). CLAUDE.md + .claude/rules/ + Skills 시스템을 갖추고 있으며, 2026년 2월 Anthropic 공식 마켓플레이스에 등록되었다. Skills 저장소는 GitHub에서 11.2만 스타를 기록했다. 2026년 2월 G 시리즈 투자 라운드에서 연환산 매출 25억 달러를 공개했다. 근거 등급: 1급. 출처: https://code.claude.com/docs/en/claude-directory

  • JetBrains AI Pulse Survey (2026.1). 전 세계 10,000명 이상의 전문 개발자를 대상으로 한 설문 조사로, 8개 언어로 현지화되었습니다. Claude Code의 CSAT(고객 만족도)는 91%, NPS(순추천지수)는 54로 업계 최고 수준입니다. Claude Code의 업무 현장 채택률은 18%로, 9개월 만에 3%에서 6배 성장했으며, 북미에서는 24%를 기록했습니다. Copilot은 업무 현장 채택률 29%를 기록했지만 성장세는 정체되었고, Cursor는 18%를 기록했습니다. 증거 수준: 1급. 출처: https://www.jetbrains.com/lp/tools/ai-tools/

  • Pragmatic Engineer Newsletter (2026.2). 15,000명의 개발자를 대상으로 한 설문 조사에서, 46%가 Claude Code를 “가장 선호하는 도구”로 꼽았으며, Cursor는 19%, Copilot은 9%를 기록했습니다. 증거 수준: 1급. 출처: https://newsletter.pragmaticengineer.com/

  • Alibaba Qoder (2025.8 → 2026.7). 2025년 8월 알리바바가 출시했으며, 2026년 5월 15일 Qoder 1.0이 Autonomous Agent Development Workbench로 업그레이드되었다. Spec-Driven Workflow, Quest Mode, Expert Mode, RepoWiki를 갖췄다. 2026년 5월 28일에는 Cloud Agents(관리형 에이전트 런타임)를, 2026년 7월 21일에는 Qoder Security를 발표했다. 2026년 5월 기준 글로벌 사용자 수는 500만 명을 돌파했으며, DingTalk CLI와 통합되었다. 2026년 5월 20일, Tongyi Lingma가 Qoder CN으로 명칭을 변경했다. 근거 수준: 1급. 출처: https://www.alibabacloud.com/en/marketplace/qoder ; https://baike.baidu.com/en/item/Qoder/1427525

  • vibecoding.app / thebcms.com / tfir.io (2026년 상반기). Spec Kit 5단계 명령어, SDD 도구 평가 비교, EARS 표기법. 근거 수준: 2차(제3자 평가). 출처: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development

  • EU AI Act / Code of Practice (2026.8.2 전면 시행). 고위험 AI 시스템 규제 준수 기한은 2026.8.2까지이며, 기존 GPAI 모델은 2027.8.2까지 유예됩니다. 위반 시 최대 3,500만 유로 또는 글로벌 매출의 7%에 해당하는 벌금이 부과됩니다. Art. 9-15는 위험 관리, 데이터 거버넌스, 문서 투명성, 인간 감독, 정확성 및 견고성 요건을 규정합니다. 증거 등급: 1급(법령 + 2차 규제 준수 분석). 출처: 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). 결함의 44%가 컨텍스트 부족에서 비롯됩니다. 증거 등급: 2급(벤더 보고서). 출처: https://www.qodo.ai/reports/state-of-ai-code-quality/

#慢慢学AI001: IAIUSE 연구형 자문 블로그

중국의 AI 기술 블로그

이 블로그는 IAIUSE 연구형 자문 블로그입니다. 중국의 전기통신, 금융, 제조, 전자상거래 업계의 CIO와 의사결정자들을 위한 자문 블로그입니다.

중국의 AI 기술 개발과 규제

중국은 AI 기술 개발을 적극적으로推진하고 있습니다. 중국 정부는 AI 기술 개발을 지원하고 규제를 강화하고 있습니다. 중국의 AI 기술 개발은 중국의 전기통신, 금융, 제조, 전자상거래 업계에 큰 영향을 미치고 있습니다.

중국의 AI 기술 개발과 규제의 특징

중국은 AI 기술 개발을 적극적으로推진하고 있습니다. 중국 정부는 AI 기술 개발을 지원하고 규제를 강화하고 있습니다. 중국의 AI 기술 개발은 중국의 전기통신, 금융, 제조, 전자상거래 업계에 큰 영향을 미치고 있습니다.

  • 중국의 AI 기술 개발은 중국의 전기통신, 금융, 제조, 전자상거래 업계에 큰 영향을 미치고 있습니다.
  • 중국 정부는 AI 기술 개발을 지원하고 규제를 강화하고 있습니다.
  • 중국의 AI 기술 개발은 중국의 전기통신, 금융, 제조, 전자상거래 업계에 큰 영향을 미치고 있습니다.

중국의 AI 기술 개발과 규제의 사례

중국은 AI 기술 개발을 적극적으로推진하고 있습니다. 중국 정부는 AI 기술 개발을 지원하고 규제를 강화하고 있습니다. 중국의 AI 기술 개발은 중국의 전기통신, 금융, 제조, 전자상거래 업계에 큰 영향을 미치고 있습니다.

중국의 AI 기술 개발과 규제의 사례

  • 중국의 전기통신 업계의 사례: 중국의 전기통신 업계는 AI 기술 개발을 적극적으로推진하고 있습니다. 중국 정부는 전기통신 업계의 AI 기술 개발을 지원하고 규제를 강화하고 있습니다.
  • 중국의 금융 업계의 사례: 중국의 금융 업계는 AI 기술 개발을 적극적으로推진하고 있습니다. 중국 정부는 금융 업계의 AI 기술 개발을 지원하고 규제를 강화하고 있습니다.
  • 중국의 제조 업계의 사례: 중국의 제조 업계는 AI 기술 개발을 적극적으로推진하고 있습니다. 중국 정부는 제조 업계의 AI 기술 개발을 지원하고 규제를 강화하고 있습니다.
  • 중국의 전자상거래 업계의 사례: 중국의 전자상거래 업계는 AI 기술 개발을 적극적으로推진하고 있습니다. 중국 정부는 전자상거래 업계의 AI 기술 개발을 지원하고 규제를 강화하고 있습니다.

중국의 AI 기술 개발과 규제의 영향

중국은 AI 기술 개발을 적극적으로推진하고 있습니다. 중국 정부는 AI 기술 개발을 지원하고 규제를 강화하고 있습니다. 중국의 AI 기술 개발은 중국의 전기통신, 금융, 제조, 전자상거래 업계에 큰 영향을 미치고 있습니다.

중국의 AI 기술 개발과 규제의 영향

  • 중국의 전기통신 업계에 큰 영향을 미치고 있습니다.
  • 중국의 금융 업계에 큰 영향을 미치고 있습니다.
  • 중국의 제조 업계에 큰 영향을 미치고 있습니다.
  • 중국의 전자상거래 업계에 큰 영향을 미치고 있습니다.

중국의 AI 기술 개발과 규제의 전망

중국은 AI 기술 개발을 적극적으로推진하고 있습니다. 중국 정부는 AI 기술 개발을 지원하고 규제를 강화하고 있습니다. 중국의 AI 기술 개발은 중국의 전기통신, 금융, 제조, 전자상거래 업계에 큰 영향을 미치고 있습니다.

중국의 AI 기술 개발과 규제의 전망

  • 중국의 전기통신 업계는 AI 기술 개발을 적극적으로推진할 것입니다.
  • 중국의 금융 업계는 AI 기술 개발을 적극적으로推진할 것입니다.
  • 중국의 제조 업계는 AI 기술 개발을 적극적으로推진할 것입니다.
  • 중국의 전자상거래 업계는 AI 기술 개발을 적극적으로推진할 것입니다.

중국의 AI 기술 개발과 규제의 참고 문헌

  • 《중국의 AI 기술 개발과 규제》 (중국 AI 기술 개발과 규제 연구소)
  • 《중국의 전기통신 업계의 AI 기술 개발과 규제》 (중국 전기통신 업계 AI 기술 개발과 규제 연구소)
  • 《중국의 금융 업계의 AI 기술 개발과 규제》 (중국 금융 업계 AI 기술 개발과 규제 연구소)
  • 《중국의 제조 업계의 AI 기술 개발과 규제》 (중국 제조 업계 AI 기술 개발과 규제 연구소)
  • 《중국의 전자상거래 업계의 AI 기술 개발과 규제》 (중국 전자상거래 업계 AI 기술 개발과 규제 연구소)
]]> AI 코드 결함률 1.7배, 보안 취약점 2.74배 — AI는 규칙을 보지 못한다. Spec Kit, Kiro, Codex, Claude Code, Qoder 5개 플랫폼이 2026 H1 CLAUDE.md로 전환한다. 【Spec-Driven Development】स्पेक लिखना AI युग का सबसे ROI-वाला इंजीनियरिंग कदम — AI युग में सॉफ्टवेयर इंजीनियरिंग का बदलाव — Learn AI Slowly 177 https://iaiuse.com/hi/posts/spec-driven-development-%E0%A4%B5%E0%A4%BF%E0%A4%95%E0%A4%BE%E0%A4%B8-%E0%A4%AE%E0%A5%87%E0%A4%82-%E0%A4%B8%E0%A5%8D%E0%A4%AA%E0%A5%87%E0%A4%95-%E0%A4%B2%E0%A4%BF%E0%A4%96%E0%A4%A8%E0%A4%BE-ai-%E0%A4%AF%E0%A5%81%E0%A4%97-%E0%A4%95%E0%A4%BE-%E0%A4%B8%E0%A4%AC%E0%A4%B8%E0%A5%87-%E0%A4%89%E0%A4%9A%E0%A5%8D%E0%A4%9A-roi-%E0%A4%87%E0%A4%82%E0%A4%9C%E0%A5%80%E0%A4%A8%E0%A4%BF%E0%A4%AF%E0%A4%B0%E0%A4%BF%E0%A4%82%E0%A4%97-%E0%A4%95%E0%A4%BE%E0%A4%B0%E0%A5%8D%E0%A4%AF 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z

डेटा स्रोत: CodeRabbit 2025.12 / New Relic 2026 रिपोर्ट, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms घोषणा, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse। केस स्टडीज़ प्रतिनिधि परिदृश्यों का सारांश हैं, किसी विशेष कंपनी का संकेत नहीं देते।

आपकी सबसे बड़ी गलती टूल न खरीदना नहीं है—CLAUDE.md न लिखना है

एक प्रमुख भारतीय निजी क्षेत्र के बैंक (HDFC जैसे) के CIO ने मुझसे शिकायत की: AI टूल खरीदे गए, मॉडल डिप्लॉय हुए, टीम को ट्रेनिंग दी गई—फिर भी 2026 की पहली छमाही में डिलीवरी साइकिल में लगभग कोई सुधार नहीं आया। कोर सिस्टम ग्रुप का प्रमुख और भी सीधा था: “AI जो कोड लिखता है वह चल जाता है, लेकिन हर बार उसे दोबारा लिखना पड़ता है—उसे हमारे बैंक के नियमों की समझ नहीं है, RBI की साइबर सुरक्षा आवश्यकताओं की समझ नहीं है, और न ही उसे पता है कि उस 30 साल पुराने COBOL-आधारित कोर बैंकिंग सिस्टम से कैसे जुड़ना है।”

समस्या यह नहीं है कि AI पर्याप्त सक्षम नहीं है, बल्कि यह है कि आपने नियम लिखे ही नहीं हैं। CodeRabbit ने दिसंबर 2025 में 470 ओपन-सोर्स PRs के विश्लेषण में एक व्यापक रूप से उद्धृत आँकड़ा पेश किया: AI-सहयोग वाले PRs में औसतन 10.83 समस्याएँ पाई गईं, जबकि पूरी तरह मानव-निर्मित PRs में 6.45 — यानी 1.7 गुना, मानव-निर्मित कोड की तुलना में 70% अधिक बग। 2026 तक कहानी नहीं बदली: New Relic ने अपनी 2026 State of AI Coding Report में पाया कि 78% टीमों ने AI कोड प्रोडक्शन में जाने के बाद अधिक इंसीडेंट रिपोर्ट किए, और 62% तकनीकी नेताओं ने स्वीकार किया कि उनकी टीमें “बिना लाइन-बाय-लाइन समीक्षा के आत्मविश्वास से AI कोड शिप कर देती हैं” (New Relic आधिकारिक रिपोर्ट 2026, 0.866 स्कोर, प्राथमिक स्रोत)। दोनों डेटा सेट एक ही बात कहते हैं — AI में क्षमता की कमी नहीं है, कमी है संदर्भ (context) की।

अगस्त 2026 के इस समय बिंदु पर, “AI ट्रांसफॉर्मेशन में तेज़ी” की हर कहानी को एक तुलनात्मक ढाँचे में देखना ज़रूरी है:

| श्रेणी | प्रगति (2026 H1) | प्रतिवाद (2026 H1) |
|—|—|—|—|
| EY | Microsoft 365 Copilot को 150,000 कर्मचारियों तक पहुँचाया, 25 लाख घंटे / 250 मिलियन डॉलर की बचत; 4 लाख वैश्विक कर्मचारियों तक विस्तार | साथ ही यह स्वीकार किया कि 95% गति वृद्धि और 37% वित्तीय परिचालन लागत में कमी की शर्त “पहले मानकीकरण” है |
| Atos | 54 देशों / 56,000 कर्मचारियों तक तैनाती; साथ ही 19,000 AI एजेंट चला रहा है, जिसमें एकीकृत पहचान/सुरक्षा/अनुपालन/शासन नियंत्रण तल है | “पहले Agent 365 की शासन क्षमता लॉन्च करें, फिर स्केल करें” के सिद्धांत पर कायम |
| Microsoft स्वयं | 2026 Work Trend Index: 82% नेता अगले 12-18 महीनों में AI एजेंटों से कार्यबल विस्तार की योजना बना रहे हैं | उसी अवधि में स्वीकार किया कि “संगठनात्मक परिवर्तन की गति व्यक्तिगत उपयोग से पीछे है” — यह Frontier Firm अवधारणा का मूल विरोधाभास है |

स्रोत: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5; New Relic 2026 State of AI Coding Report.

ये दोनों तुलनाएँ एक ही बात साबित करती हैं: बिना governance के, scale का मतलब सिर्फ़ risk को N से गुणा करना है। EY/Atos/Microsoft की “तेज़ी” मॉडल की तेज़ी नहीं है, बल्कि “संगठन ने पहले ही तय कर लिया कि AI का उपयोग कैसे करना है”। यही वजह है कि Spec-Driven Development (SDD, मानक-संचालित विकास) 2026 H1 में वास्तव में mainstream बना — ऐसा इसलिए नहीं कि engineers को documentation पसंद है, बल्कि इसलिए कि बिना specs के 19,000 agents वाले environment में जीवित रहना अब संभव नहीं है।

यह लेख तीन बातें स्पष्ट करता है: 1) AI code में defects human-written code की तुलना में 1.7 गुना से अधिक गंभीर क्यों होते हैं; 2) GitHub, AWS, OpenAI, Anthropic, Alibaba — ये पाँचों platforms 2026 H1 में एक ही paradigm की ओर कैसे बढ़े — documentation के माध्यम से AI व्यवहार को नियंत्रित करना; 3) Spec-driven approach एक organizational capability क्यों है, न कि सिर्फ tool choice, और 2026 H1 में इसके तीन implementation phases क्या हैं।

AI कोड बनाम मानव कोड: दोष वितरण (470 ओपन सोर्स PR विश्लेषण) CodeRabbit 2025.12 रिपोर्ट｜सभी संख्याएँ AI/मानव गुणक अनुपात (आधार 1.0)

बार लंबाई = AI दोष मानव का गुणक; आधार 1.0× = मानव स्तर

आधार 1.0×

कुल समस्याएँ

1.7×
AI 10.83 बनाम मानव 6.45 / PR

तर्क/शुद्धता त्रुटियाँ

1.75×

कोड गुणवत्ता/रखरखाव

1.64×

सुरक्षा निष्कर्ष (समग्र)

1.57×

पासवर्ड गलत प्रबंधन

1.88×

XSS कमजोरियाँ

2.74×
↑ उच्चतम

बिना मानकों वाला AI कोड, हर आयाम में मानव से ऊपर
वित्त/दूरसंचार = अनुपालन मिलान, पासवर्ड प्रबंधन, संवेदनशील फ़ील्ड एन्क्रिप्शन, AI सब अनदेखा

एक: AI दोष दर मॉडल की समस्या नहीं है, यह कॉन्टेक्स्ट की समस्या है

CodeRabbit की रिपोर्ट में एक पंक्ति बार-बार उद्धृत की गई है: “AI में स्थानीय व्यावसायिक तर्क का अभाव है: मॉडल सिमेंटिक समझ के बजाय सांख्यिकीय अनुमान से कोड पैटर्न का विश्लेषण करते हैं। सख्त बाधाओं के बिना, वे उन सिस्टम नियमों को अनदेखा कर देते हैं जिन्हें वरिष्ठ इंजीनियर आंतरिक रूप से आत्मसात कर लेते हैं।”

यह पंक्ति बताती है कि CodeRabbit का अपना AI कोडिंग प्लेटफ़ॉर्म (एक कंपनी जो विशेष रूप से AI कोड रिव्यू करती है) इस डेटा को दूसरों से पहले क्यों देख पाया — वे हर दिन हजारों PR देखते हैं, हर दिन देखते हैं कि AI द्वारा लिखा गया कोड कैसा दिखता है। “सबसे महत्वपूर्ण” खोज कुल संख्या नहीं है, बल्कि वितरण है:

  • लॉजिक/शुद्धता +75%: व्यावसायिक तर्क त्रुटियाँ, डिपेंडेंसी त्रुटियाँ, कंट्रोल फ्लो त्रुटियाँ, कॉन्फ़िगरेशन त्रुटियाँ — ये समस्याएँ टेस्टिंग में ज़रूरी नहीं कि सामने आएँ, लेकिन प्रोडक्शन एनवायरनमेंट में इनसिडेंट का कारण बनती हैं।
  • कोड क्वालिटी +64%: नेमिंग में असंगति, अस्पष्ट संरचना, प्रोजेक्ट पैटर्न का उल्लंघन — यह “सबसे बड़ा अंतर वाली श्रेणी” है। वरिष्ठ इंजीनियर एक नज़र में पहचान लेते हैं कि “यह हमारे यहाँ का लेखन-शैली नहीं है।”
  • सुरक्षा +57% (XSS श्रेणी में सबसे अधिक 2.74×): पासवर्ड का अनुचित प्रबंधन (1.88×), असुरक्षित ऑब्जेक्ट रेफरेंस (1.91×), संवेदनशील जानकारी का लीक, असुरक्षित डिसीरियलाइज़ेशन (1.82×) — वित्तीय उद्योग में, यह “क्या यह काम करेगा” का सवाल नहीं है, बल्कि “क्या इसे जारी किया जा सकता है” का सवाल है।

समस्या यह नहीं है कि AI काफ़ी सक्षम नहीं है। समस्या यह है कि वह देख नहीं पाता।

उस CIO की असली बाधा पर वापस आते हैं — फाइनेंशियल कोर सिस्टम में AI के तीन ठोस फेलियर पॉइंट:

पहला, AI 30 साल पुराने रेकन्सिलिएशन लॉजिक को नहीं देख पाता। बैंक के रिस्क-कंट्रोल नियम कोर सिस्टम के स्टोर्ड प्रोसीजर में लिखे हैं — 30 साल पहले लिखे गए, और आज किसी को पूरी तरह याद नहीं। AI द्वारा जनरेट किया गया कोड लॉजिकली सही लगता है, लेकिन प्रोडक्शन एनवायरनमेंट में वह उस रेकन्सिलिएशन चेक को ट्रिगर कर देता है जिसे कोई याद नहीं रखता — और पूरा बैच ट्रांज़ैक्शन फेल हो जाता है।

दूसरा, AI कंप्लायंस बाधाओं को नहीं देख पाता। पासवर्ड को की-मैनेजमेंट सिस्टम से गुज़रना ही होगा, सेंसिटिव फ़ील्ड्स को एन्क्रिप्ट करके स्टोर करना ही होगा, लॉग्स में कस्टमर की जानकारी प्रिंट नहीं हो सकती — ये रेगुलेटरी हार्ड कंस्ट्रेंट्स हैं, जो आंतरिक नीतियों में लिखे हैं। AI को इनकी जानकारी नहीं होती, इसलिए वह ऐसा कोड लिखता है जो चल तो जाता है लेकिन कंप्लायंस रिव्यू पास नहीं कर पाता।

तीसरा, AI आपका टेक्निकल डेट नहीं देख पाता। वह 30 साल पुराना होस्ट सिस्टम अपने खुद के इंटरफ़ेस प्रोटोकॉल पर चलता है, और उसका डॉक्यूमेंटेशन लंबे समय से गायब है। AI जनरल RESTful स्टैंडर्ड के हिसाब से कोड लिखता है, और जब डिप्लॉय होता है तो पता चलता है कि इंटरफ़ेस मैच नहीं कर रहा — दो हफ़्ते का रीवर्क।

अब New Relic के दूसरे आँकड़ों पर वापस चलते हैं: 62% टीमें “पूरे आत्मविश्वास के साथ बिना रिव्यू किए” AI कोड शिप कर देती हैं, और 78% ने प्रोडक्शन में जाने के बाद ज़्यादा इंसीडेंट रिपोर्ट किए। इन दोनों आँकड़ों को एक साथ रखें, तो निष्कर्ष यही निकलता है — AI कोड में डिफेक्ट होना अपने आप में समस्या नहीं है; “मुझे नहीं पता कि AI कोड में क्या डिफेक्ट है” — यही असली समस्या है।

विशिष्ट परिदृश्य: HDFC जैसे एक प्रमुख भारतीय निजी बैंक ने अपने कोर बैंकिंग सिस्टम के जोखिम-नियंत्रण मॉड्यूल को विकसित करने के लिए AI-सहायता प्राप्त कोडिंग शुरू की। तीन महीनों में, अनुपालन समीक्षा की अस्वीकृति दर में उल्लेखनीय वृद्धि हुई। मुख्य समस्याएँ थीं: RBI की साइबर सुरक्षा फ्रेमवर्क के तहत पासवर्ड प्रबंधन, DPDP Act 2023 के अनुसार संवेदनशील फ़ील्ड एन्क्रिप्शन, CERT-In Directions के अनुसार लॉग अनुपालन जैसे आंतरिक नियम। ये नियम आंतरिक दस्तावेज़ों में लिखे थे, लेकिन AI उन्हें देख नहीं पा रहा था। बाद में, टीम ने मुख्य नियमों को CLAUDE.md में लिख दिया, और अस्वीकृति दर स्पष्ट रूप से गिर गई।

दूसरा भाग: 2026 H1 में पाँच प्रमुख प्लेटफ़ॉर्म: अलग-अलग रास्ते, एक ही मंज़िल — “स्पेक-संचालित”

जुलाई 2025 में GitHub ने Spec Kit जारी किया। 2026 की शुरुआत में AWS Kiro, OpenAI Codex, और Anthropic Claude Code — सभी ने इसे पूरा किया। मई 2026 में Alibaba Qoder ने “Spec-Driven Workflow” को अपनी उत्पाद पहचान में शामिल किया। 2026 H1 तक, पाँचों प्रमुख प्लेटफ़ॉर्म एक ही प्रतिमान पर पहुँच गए — दस्तावेज़ों के ज़रिए AI व्यवहार को नियंत्रित करना। यह किसी एक कंपनी का आविष्कार नहीं है, बल्कि “AI कोड गुणवत्ता संकट” के प्रति उद्योग की सामूहिक प्रतिक्रिया है।

पाँच प्लेटफ़ॉर्म के मानक-संचालित पथ (2025-2026 H1) GitHub Spec Kit ओपन सोर्स 2025.9 constitution.md पाँच-चरण गेटिंग: constitution → specify → plan → tasks → implement मॉडल-अज्ञेय, 8+ एजेंट समर्थन Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md तीन-चरण वर्कफ़्लो: आवश्यकता → डिज़ाइन → कार्य spec-संचालित IDE वर्कफ़्लो में हुक ट्रिगर स्वचालित एजेंट अनुपालन/ऑडिट हुक पूर्व-स्थापित spec लिखे बिना शुरू नहीं होता OpenAI Codex 2025-2026 AGENTS.md + स्किल्स सिस्टम संयोजनीय निर्देश सेट टीम-स्तरीय साझा कॉन्फ़िग 5M+ साप्ताहिक उपयोगकर्ता (2026.6) गैर-डेवलपर 20% प्रोग्रामिंग से सामान्य एजेंट तक Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + कौशल (आधिकारिक बाज़ार 2026.2) + MCP पारिस्थितिकी तंत्र CSAT 91% / NPS 54 $2.5B ARR（2026.2） GitHub 11.2 लाख स्टार्स Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Quest Mode स्वायत्त निष्पादन + Expert Mode टीम + RepoWiki संदर्भ 5M+ वैश्विक उपयोगकर्ता (2026.5) 2026.7.21 Qoder Security डिंगटॉक CLI जुड़ा हुआ साझा प्रतिमान: "हम AI के साथ कैसे सहयोग करें" को स्पष्ट रूप से दस्तावेज़ में लिखें, रिपॉजिटरी में रखें सभी लोगों और सभी AI एजेंटों को एक ही मानक पर काम करने दें — यही मानक-संचालित का सार है

आइए देखें कि 2026 H1 में प्रत्येक प्लेटफ़ॉर्म ने क्या नए कदम उठाए:

GitHub Spec Kit: संदर्भ कार्यान्वयन, पाँच-चरणीय गेटिंग। सितंबर 2025 में ओपन-सोर्स किया गया, 2026 की पहली छमाही तक यह उद्योग का संदर्भ कार्यान्वयन बन चुका है। 5 मुख्य कमांड + 2 पूरक: /speckit.constitution (अनिवार्य सिद्धांत), /speckit.specify (क्या करना है और क्यों), /speckit.plan (कैसे बदलना है), /speckit.tasks (कार्यों में विभाजन), /speckit.implement (निष्पादन), साथ ही /clarify और /analyze। इसका प्रमुख डिज़ाइन मॉडल-अज्ञेय है — एक ही spec/plan/tasks फ़ाइल किसी विशेष निष्पादन एजेंट से बंधी नहीं होती; Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf, Qwen Code — सभी इसे जोड़ सकते हैं। यही इसे “संगठन-स्तरीय SDD प्रोटोकॉल” बनाता है, न कि GitHub का विशेष उत्पाद (vibecoding.app मूल्यांकन 2026.6, 0.816 स्कोर, द्वितीयक स्रोत)।

AWS Kiro: जब स्पेक-संचालित विकास IDE के अंदर ही बस जाए। जुलाई 2025 में लॉन्च हुआ, 2026 की पहली छमाही में यह एक पूर्ण Agent IDE के रूप में विकसित हो गया। इसका वर्कफ़्लो तीन चरणों में बँटा है: आवश्यकता (Requirements) → डिज़ाइन → कार्य (Tasks)। Spec Kit से इसका मुख्य अंतर “हुक” (hooks) में है — Kiro की spec फ़ाइलें पहले से परिभाषित एजेंट एक्शन को ट्रिगर कर सकती हैं, जिससे कंप्लायंस, ऑडिट, या डिप्लॉयमेंट जैसे बाहरी सिस्टम पर निर्भर कदमों को सीधे वर्कफ़्लो में प्री-एम्बेड किया जा सकता है। अगर आप टीम को स्पेक लिखने के लिए बाध्य करना चाहते हैं, तो Kiro चुनें — क्योंकि जब तक आप spec नहीं लिखेंगे, Kiro शुरू ही नहीं होगा (AWS Kiro आधिकारिक, जुलाई 2025; Kiro.dev दस्तावेज़, 2026)।

OpenAI Codex: AGENTS.md + कम्पोज़ेबल Skills। 2025-2026 ने AGENTS.md को इकोसिस्टम के केंद्र में ला दिया है। Skills, 2026 H1 का प्रमुख विस्तार है: “एक्सेल शीट पढ़ना,” “SQL जनरेट करना,” “डेटा माइग्रेशन चलाना” जैसे कार्यों को पहले से तैयार मॉड्यूल की तरह जोड़ा जा सकता है, बिल्कुल लेगो ब्लॉक्स की तरह। जून 2026 तक Codex की साप्ताहिक सक्रियता 5 मिलियन पार कर गई, जिसमें 20% गैर-डेवलपर हैं — यह एक अनदेखा संकेत है: स्पेक-ड्रिवन डेवलपमेंट अब सिर्फ इंजीनियरिंग टीमों का मामला नहीं रहा, बल्कि पूरे संगठन का है। प्रोडक्ट, ऑपरेशंस और रिस्क टीमें भी AGENTS.md लिख रही हैं (OpenAI 2026.6.2 घोषणा; thebcms.com रिव्यू 2026, 0.801 स्कोर)।

Claude Code: CLAUDE.md + .claude/rules/ + Skills। Anthropic अपनी प्रोजेक्ट इंस्ट्रक्शन फाइलों को CLAUDE.md (फरवरी 2026 में आधिकारिक मार्केटप्लेस में आया), .claude/rules/ (डायरेक्ट्री-आधारित लेयर्ड रूल्स), और Skills (साझा करने योग्य वर्कफ़्लो) कहता है। Claude Code 2026 की पहली छमाही में डेवलपर्स के बीच सबसे ज़्यादा संतुष्टि वाला टूल है — JetBrains 2026.1 सर्वे के अनुसार CSAT स्कोर 91% और NPS 54 है, और दो स्वतंत्र सर्वे (Pragmatic Engineer 2026.2) भी इसकी पुष्टि करते हैं। यह AI कोडिंग टूल्स की रेस में अभी तक का सबसे ऊँचा स्कोर है (uvik.net 2026.5, 0.956 स्कोर, प्राथमिक स्रोतों का समेकन)। Claude Code ने 9 महीनों में शून्य से 2.5 बिलियन डॉलर की वार्षिक आय (2026.2 Anthropic G राउंड के आंकड़े) हासिल की है, और GitHub पर 112,000 स्टार्स (Skills रिपॉजिटरी) — डेवलपर्स का यह समर्थन साफ़ संकेत है कि स्पेक-ड्रिवन (नियम-आधारित) दृष्टिकोण की वास्तविक कीमत है।

Alibaba Qoder: चीन के बाज़ार में नियामक अनुपालन पर आधारित विकास। अगस्त 2025 में लॉन्च हुआ, और 15 मई 2026 को इसका 1.0 संस्करण जारी किया गया, जिसके साथ ही यह आधिकारिक तौर पर “AI IDE” से बदलकर “Autonomous Agent Development Workbench” बन गया। इसका Spec-Driven Workflow, Quest Mode (स्वायत्त मल्टी-फ़ाइल कार्य), Expert Mode (विशेषज्ञ टीम का समानांतर कार्य) और RepoWiki (रिपॉज़िटरी नॉलेज ग्राफ) के साथ एक साथ पेश किया गया। 28 मई 2026 को Cloud Agents (पूरी तरह से प्रबंधित एजेंट रनटाइम) लॉन्च हुआ, 21 जुलाई को Qoder Security (अनुपालन और सुरक्षा क्षमताएँ) आया, और उसी महीने Mobile संस्करण (Android/iOS/鸿蒙) भी जारी किया गया। मई 2026 तक, दुनिया भर में इसके 5 मिलियन से अधिक उपयोगकर्ता हो चुके हैं, और DingTalk CLI इसे अपने समर्थित एजेंट निष्पादन वातावरणों में से एक के रूप में सूचीबद्ध करता है (Yahoo Finance 2025; Alibaba Cloud आधिकारिक 2026; Baidu Baike 2026.7)।

साझा दृष्टिकोण: “हम AI के साथ कैसे सहयोग करते हैं” इसे स्पष्ट रूप से एक दस्तावेज़ के रूप में लिखें, उसे रिपॉजिटरी में रखें, और सुनिश्चित करें कि सभी लोग और सभी AI एजेंट एक ही मानक के अनुसार काम करें। पाँचों प्लेटफ़ॉर्म के कार्यान्वयन के विवरण अलग-अलग हैं (फ़ाइल नाम/चरणों की संख्या/हुक तंत्र), लेकिन लक्ष्य बिल्कुल एक जैसा है।

यह सब 2026 की पहली छमाही में एक साथ क्यों हो रहा है? क्योंकि AI की क्षमता की बाधा अब पार हो चुकी है — Claude Code का स्वायत्त एजेंट, Codex का मल्टी-एजेंट समानांतर निष्पादन, Cursor का मल्टी-फ़ाइल रीफैक्टरिंग। AI अब “ऑटो-कम्प्लीशन टूल” नहीं, बल्कि “एक सहकर्मी” है। जो ऑनबोर्डिंग दस्तावेज़ आप किसी नए सहकर्मी को देते हैं, वही AI को भी दिखना चाहिए।

तीन: स्पेक-ड्रिवन एक संगठनात्मक क्षमता है, टूल का चुनाव नहीं

यह निर्णयकर्ताओं के लिए सबसे महत्वपूर्ण बात है। स्पेक-ड्रिवन का मतलब टूल चुनना नहीं है, बल्कि यह परिभाषित करना है कि “हमारा संगठन AI के साथ कैसे सहयोग करता है।” आप GitHub Spec Kit चुनें या Claude Code — यह महत्वपूर्ण नहीं है। असली सवाल यह है: क्या आपने स्पेक को एक दस्तावेज़ के रूप में लिखा, उसे रिपॉजिटरी में रखा, और सभी लोगों और AI को उसी के अनुसार काम करने के लिए बाध्य किया?

इसके बिना, कितना भी अच्छा टूल हो, वह सिर्फ़ टीम को और तेज़ी से और ज़्यादा तकनीकी कर्ज़ बनाने में मदद करेगा।

इसे 2026 H1 के बड़े पैमाने पर तैनाती के नज़रिए से देखें, तो सबूत और मज़बूत हो जाते हैं। Microsoft ने जुलाई 2026 की अपनी FY26 retrospective में EY और Atos के दोनों केस स्टडीज़ को “Frontier Firm” टेम्पलेट के रूप में पेश किया — वजह यह नहीं कि मॉडल नया है, बल्कि इसलिए कि दोनों कंपनियों ने सबसे पहले “AI का उपयोग कैसे करें” का सवाल हल किया:

EY: पहले शासन-व्यवस्था, फिर स्केल पर नतीजे। EY ने 2024-2025 में Microsoft 365 Copilot को 1.5 लाख लोगों तक पहुँचाया, जिससे 25 लाख घंटे और लगभग 250 मिलियन डॉलर की बचत हुई। शर्त यह थी कि “AI गवर्नेंस फ्रेमवर्क पहले तैयार किया गया”: EY ने Power Platform, Copilot Studio, Azure, Foundry और Fabric का उपयोग करके एक एकीकृत टूलचेन बनाई, जिसमें नियम/अनुपालन/ऑडिट को एक ही आधार पर रखा गया। इसी के बाद 95% स्पीड-अप, 37% वित्तीय संचालन लागत में कमी और 90% तक मैन्युअल वर्कफ़्लो में कटौती संभव हुई। EY के VP ने 2026 AI Tour पर सीधे कहा: **”हमने पहले AI तैनात करके बाद में गवर्नेंस नहीं जोड़ा; हमने पहले गवर्नेंस जोड़ा, फिर AI तैनात किया”**।

Atos: 19,000 एजेंट्स के लिए एकीकृत नियंत्रण तल (Unified Control Plane)।
Atos दुनिया के पहले संगठनों में से है जिसने Microsoft 365 E7 (Frontier Suite) को अपनाया और Copilot को 54 देशों में 56,000 कर्मचारियों तक पहुँचाया। वे एक साथ 19,000 AI एजेंट चला रहे हैं — आंतरिक IT, बिज़नेस यूनिट्स से लेकर क्लाइंट प्रोजेक्ट्स तक, सभी Foundry और Copilot Studio का उपयोग करके एजेंट बना रहे हैं। Atos की सफलता की कुंजी है “एक नियंत्रण तल”: Entra (पहचान) + Defender (सुरक्षा) + Intune (डिवाइस) + Purview (अनुपालन) + Agent 365 (एजेंट गवर्नेंस) — ये पाँचों एक साथ बंधे हैं। यह बंधाव, भारतीय वित्तीय क्षेत्र में उसी तरह है जैसे “DPDP Act 2023 के तहत डेटा संरक्षण + CERT-In Directions 2022 के तहत साइबर सुरक्षा रिपोर्टिंग + RBI की बैंकिंग अनुपालन + MeitY के एल्गोरिदम पंजीकरण (Digital India Act ड्राफ्ट) + मॉडल गवर्नेंस” — यह एक शासन संरचना है, न कि केवल एक AI टूल।

Microsoft का अपना “संगठनात्मक परिवर्तन विरोधाभास”। 2026 Work Trend Index रिपोर्ट में Microsoft ने खुद एक बात स्वीकार की है: “संगठनात्मक परिवर्तन की गति व्यक्तिगत उपयोग से पीछे है”। उन्होंने 20,000 AI उपयोगकर्ताओं पर सर्वेक्षण किया, जिसमें 82% नेताओं ने अगले 12-18 महीनों में AI एजेंटों के साथ कार्यबल विस्तार की योजना बनाई है, लेकिन केवल 24% ने एंटरप्राइज़ स्तर पर तैनाती पूरी की है। 81% नेताओं का अनुमान है कि AI एजेंट AI रणनीति में मध्यम या बड़े पैमाने पर एकीकृत होंगे — लेकिन फिर भी केवल 24% ने ऐसा किया है। इसका मतलब है कि अधिकांश उद्यम “तैयारी” और “पूर्णता” के बीच 12-18 महीनों की दूरी पर हैं, और इस दूरी को कैसे भरा जाए, मानक-संचालित दृष्टिकोण मुख्य आधार है।

स्रोत: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, PDF प्राथमिक स्रोत); Futurum Group 2026.1.26 विश्लेषण (द्वितीयक स्रोत)।

निष्कर्ष एक: मानकों में निवेश उच्च ROI है।

CodeRabbit का डेटा ROI की गणना के लिए स्पष्ट आधार देता है: AI कोड समस्या दर लगभग 1.7 गुना, सुरक्षा कमजोरियों में 2.74 गुना की कमी। इसका मतलब है:

  • कम रीवर्क (वित्तीय क्षेत्र में एक कंप्लायंस रिव्यू का रीवर्क 2-4 सप्ताह का होता है)
  • कम सुरक्षा घटनाएँ (एक डेटा लीक की घटना से जुड़े रेगुलेटरी जुर्माने और प्रतिष्ठा की हानि)
  • कम मेंटेनेंस लागत (तकनीकी कर्ज में 40% की कमी एक सामान्य आंकड़ा है)

CLAUDE.md/AGENTS.md प्रोजेक्ट स्पेसिफिकेशन लिखना AI युग में सबसे अधिक ROI देने वाला इंजीनियरिंग कदम है। EY का केस रियल-वर्ल्ड कन्वर्ज़न दिखाता है — 1.5 लाख लोगों के लिए Copilot तैनात किया, 250 मिलियन डॉलर की बचत। ध्यान दें कि EY ने यह बचत “टूल के शक्तिशाली होने” के कारण नहीं की, बल्कि इसलिए कि “स्पेसिफिकेशन ने टूल के मूल्य को साकार किया।”

दूसरा निष्कर्ष: स्पेसिफिकेशन को संगठन की प्रक्रियाओं में लिखें, न कि व्यक्तियों पर निर्भर रहें।

अगर स्पेसिफिकेशन केवल किसी वरिष्ठ इंजीनियर के दिमाग में मौजूद है, तो लोगों के आने-जाने पर वह खो जाता है। इसे इनमें समाहित करना ज़रूरी है:

  • रिपॉज़िटरी दस्तावेज़ (AGENTS.md / CLAUDE.md / constitution.md)
  • CI गेटिंग (स्पेसिफिकेशन अनुपालन की स्वचालित जाँच)
  • टीम-साझा कॉन्फ़िगरेशन (Skills सिस्टम से पूरी टीम इसका उपयोग कर सके)

मानकों को संगठन की संपत्ति बनाएं, व्यक्तिगत कौशल नहीं। यह भारतीय वित्तीय क्षेत्र में विशेष रूप से महत्वपूर्ण है—आपकी DPDP Act 2023 के तहत अनुपालन आवश्यकताएँ, RBI की सूचना सुरक्षा नियम, और व्यावसायिक नियम सभी संगठन-स्तरीय संपत्तियाँ हैं, किसी एक इंजीनियर के “व्यक्तिगत अनुभव” में बंद नहीं। Atos के 19,000 एजेंट 54 देशों में इसलिए काम कर पाते हैं क्योंकि गवर्नेंस “किसी एक व्यक्ति की समझ” नहीं है—यह “सिस्टम द्वारा अनिवार्य” है।

तीसरा निष्कर्ष: गेटिंग गति से अधिक महत्वपूर्ण है।

GitHub Spec Kit की पाँच-चरणीय गेटिंग (constitution → specify → plan → tasks → implement), Claude Code का “टेस्ट फेल होने से पहले कोड मत लिखो” सिद्धांत, और Kiro का “बिना spec लिखे प्रोजेक्ट शुरू ही नहीं होगा” — ये सभी एक ही काम करते हैं: AI और अंतिम आउटपुट के बीच “ब्रेक” लगाना। हर चरण में एक समीक्षा-योग्य उत्पाद होता है (spec.md, plan.md, tasks.md), जिसे कोड जनरेशन से पहले खारिज या संशोधित किया जा सकता है।

जितना अधिक स्वायत्त AI, उतनी अधिक गेटिंग की आवश्यकता। भारतीय वित्तीय क्षेत्र में RBI की परिवर्तन अनुमोदन समिति (Change Advisory Board, Change Advisory Board (CAB)), DPDP Act 2023 के तहत डेटा संरक्षण बोर्ड (DPB) की समीक्षा, और CERT-In की 6-घंटे की साइबर घटना रिपोर्टिंग आवश्यकता—ये सभी उत्पादन से पहले गेटिंग की प्रक्रिया हैं। AI-जनित कोड को भी इसी प्रकार की गेटिंग चाहिए, बस स्वरूप अलग हो सकता है। New Relic की 2026 रिपोर्ट में जिन 62% टीमों का उल्लेख है जो “बिना समीक्षा के आत्मविश्वास से शिप करती हैं”, वे 78% की उच्च घटना दर से इस आत्मविश्वास की कीमत चुका रही हैं।

वित्त उद्योग मानक कार्यान्वयन तीन चरण (2026 H1 व्यावहारिक संस्करण) चरण 1: नियमों की सूची बनाना 2-4 सप्ताह｜सबसे अधिक समय लेने वाला, ROI सबसे अधिक अनुपालन आवश्यकताओं की सूची (डेटा सुरक्षा/डेटा निर्यात/पंजीकरण) सुरक्षा नियम (पासवर्ड/एन्क्रिप्शन/लॉग) व्यावसायिक नियम (जोखिम नियंत्रण/लेनदेन/बिलिंग) तकनीकी बाधाएँ (पुराने इंटरफ़ेस/संस्करण सीमाएँ) विक्रेता प्रशासन (अनुबंध/ऑडिट/जिम्मेदारी) बिखरे हुए नियमों को इकट्ठा करना संरचित दस्तावेज़ में बदलना चरण 2: रिपॉजिटरी में डालना 1-2 सप्ताह｜रिपॉजिटरी में डालें, AI स्वतः लोड करे CLAUDE.md / AGENTS.md constitution.md स्किल्स परिभाषा (साझा कार्यप्रवाह) गेटेड प्रक्रिया डिज़ाइन (पाँच चरण) .claude/rules/ (स्तरीय नियम) नियमों को रिपॉजिटरी में रखें, AI स्वतः लोड करे चरण 3: संस्थागतकरण निरंतर｜टूल से संगठनात्मक क्षमता तक CI गेटिंग (स्वचालित समीक्षा) टीम साझा कॉन्फ़िग (Skills) नियमित अपडेट (त्रैमासिक समीक्षा) मेट्रिक्स (दोष दर/अनुपालन दर) एजेंट गवर्नेंस (Agent 365 स्तर 1) मानक संगठन की संपत्ति बनें, व्यक्ति पर निर्भर नहीं

पहला चरण सबसे समय लेता है, पर ROI सबसे अधिक
अधिकांश वित्तीय संगठनों के नियम दस्तावेज़/ईमेल/दिमाग में बिखरे हैं, पहली व्यवस्था 3-8 सप्ताह का निवेश

चार: 2026 H1 में वास्तविक कार्यान्वयन के तीन चरण

वित्तीय उद्योग के उदाहरण के साथ तीन-चरणीय रास्ता, अन्य उच्च-विनियमित उद्योग भी इसी पैटर्न का अनुसरण कर सकते हैं। EY और Atos के 2026 H1 के व्यावहारिक अनुभव बिल्कुल इन्हीं तीन चरणों के अनुरूप हैं।

चरण एक: नियमों की सूची बनाना (2-4 सप्ताह)।

यह सबसे समय लेने वाला लेकिन सबसे अधिक ROI देने वाला चरण है। यहाँ काम है—अलग-अलग जगहों पर बिखरे नियमों को खोजकर एक जगह इकट्ठा करना:

  • अनुपालन आवश्यकताएँ: भारतीय वित्तीय क्षेत्र के लिए न्यूनतम आधार रेखा = DPDP Act 2023 + DPDP Rules 2025 + CERT-In Directions 2022 (6-घंटे की साइबर घटना रिपोर्टिंग आवश्यकता) (इनमें से एक भी कम हो तो AI रोलआउट न करें)। इसके ऊपर RBI की साइबर सुरक्षा फ्रेमवर्क, NCIIPC की महत्वपूर्ण सूचना अवसंरचना सुरक्षा दिशानिर्देश, क्रॉस-बॉर्डर डेटा ट्रांसफर प्रतिबंध (DPDP Act की धारा 16 के अनुसार सरकारी अनुमोदन आवश्यक), और यह तय करना कि कौन सा डेटा AI को दिखाया जा सकता है
  • सुरक्षा नियम: पासवर्ड प्रबंधन, एन्क्रिप्शन मानक, संवेदनशील फ़ील्ड हैंडलिंग, लॉग आवश्यकताएँ
  • व्यावसायिक नियम: जोखिम नियंत्रण थ्रेसहोल्ड, क्लेम शर्तें, लेनदेन सीमाएँ, बिलिंग लॉजिक
  • तकनीकी बाधाएँ: लीगेसी सिस्टम इंटरफेस, डेटाबेस नामकरण, फ्रेमवर्क वर्जन सीमाएँ
  • वेंडर गवर्नेंस: कॉन्ट्रैक्ट में वेंडर से हमारे मानकों का पालन कैसे करवाएँ, वेंडर के AI उपयोग का ऑडिट कैसे करें

विशिष्ट परिदृश्य: एक भारतीय ब्रोकरेज फर्म को अपनी समीक्षा के दौरान पता चला कि नियम बड़ी संख्या में Word दस्तावेज़ों, Confluence wiki, व्यक्तिगत ईमेल और Excel शीट्स में बिखरे पड़े हैं—व्यवस्थित करने के बाद ही उन्हें एक संरचित नियम-सूची मिली। Atos का तरीका अधिक व्यवस्थित है—उन्होंने नियमों को सीधे पाँच श्रेणियों में बाँटा: “अनुपालन, सुरक्षा, व्यवसाय, तकनीक, विक्रेता”—प्रत्येक श्रेणी के लिए एक अलग गवर्नेंस वर्कफ़्लो, सभी को Agent 365 के कंट्रोल प्लेन से जोड़ा गया।

यह कोई तकनीकी काम नहीं है, बल्कि एक संगठनात्मक कार्य है—आपको अनुपालन विभाग, सुरक्षा विभाग और व्यवसाय विभाग को एक साथ लाना होगा, और ऐसे नियम लिखने होंगे जिन्हें सभी स्वीकार करें। पहली बार ऐसा करने में वित्तीय संगठनों को आमतौर पर 3-8 सप्ताह लगते हैं—लेकिन यह एक स्थायी संगठनात्मक संपत्ति है।

चरण दो: रिपॉज़िटरी में डालना (1-2 सप्ताह)।

पहले चरण में तैयार किए गए नियमों को दस्तावेज़ के रूप में लिखकर रिपॉज़िटरी में रखें। GitHub Spec Kit में constitution.md, Claude Code में CLAUDE.md, OpenAI Codex में AGENTS.md, और Alibaba Qoder में Spec Workflow का उपयोग होता है। फ़ाइल का नाम अलग है, लेकिन उद्देश्य एक ही है—AI को रिपॉज़िटरी खोलते ही नियम लोड करना।

संरचना सुझाव (2026 H1 मुख्यधारा प्रारूप):

  • परियोजना अवलोकन: यह सिस्टम क्या करता है, किसकी सेवा करता है
  • अ-विचारणीय सिद्धांत: सुरक्षा रेखा, अनुपालन रेखा, व्यावसायिक रेखा
  • तकनीकी स्टैक और बाधाएँ: कौन-सा फ्रेमवर्क, कौन-सा डेटाबेस, कौन-सा इंटरफ़ेस मानक
  • कोड मानक: नामकरण परंपरा, निर्देशिका संरचना, परीक्षण की न्यूनतम कवरेज आवश्यकता (TDD की गति अनिवार्य नहीं — बस टेस्ट कवरेज, अनिवार्य परीक्षण पथ, और निषिद्ध पथ स्पष्ट रूप से लिखें; TDD संगठन की वैकल्पिक गति है, मानक-संचालित कठोर आवश्यकता नहीं)
  • व्यावसायिक नियम: जोखिम नियंत्रण तर्क, लेन-देन नियम, बिलिंग नियम
  • अनुपालन आवश्यकताएँ: DPDP Act 2023 + DPDP Rules 2025 के तहत व्यक्तिगत डेटा संरक्षण, CERT-In Directions 2022 के तहत साइबर सुरक्षा, क्रॉस-बॉर्डर डेटा स्थानांतरण (DPDP Act की धारा 16 के अनुसार सरकारी अनुमोदन आवश्यक), RBI की नियामक रिपोर्टिंग, और AI-जनित एल्गोरिदम के लिए MeitY Digital India Act के तहत पंजीकरण आवश्यक है या नहीं
  • AI उपयोग मानक: किन परिदृश्यों में AI का उपयोग किया जा सकता है, किन परिदृश्यों में मानव समीक्षा अनिवार्य है, डेटा सीमा-पार नियम
  • विक्रेता प्रशासन: अनुबंध शर्तें, ऑडिट तंत्र, उत्तरदायित्व विभाजन

परिशिष्ट: CLAUDE.md फाइनेंस संस्करण ढाँचा (लगभग 200 पंक्तियाँ, सीधे fork करके संशोधित किया जा सकता है)

नीचे HDFC जैसे एक प्रमुख भारतीय निजी बैंक के कोर बैंकिंग सिस्टम पुनर्निर्माण के लिए CLAUDE.md ढाँचा दिया गया है, जिसे “अविचारणीय सिद्धांत → अनुपालन आवश्यकताएँ → AI उपयोग मानक → व्यावसायिक नियम → इंजीनियरिंग बाधाएँ” के क्रम में व्यवस्थित किया गया है। आपकी कंपनी को शून्य से शुरू करने की आवश्यकता नहीं है — बस खाली स्थानों में अपने विशिष्ट नियम भर दें।

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
# CLAUDE.md — <सिस्टम का नाम> AI सहयोग मानक

> लागू होने का क्षेत्र: <सिस्टम का नाम> v<संस्करण>, सभी AI एजेंट (Claude Code / Cursor / Copilot / Codex)
> इस रिपॉजिटरी पर काम करते समय इस मानक का पालन अनिवार्य है। इस दस्तावेज़ का रखरखाव <शासन समिति> द्वारा किया जाता है, त्रैमासिक समीक्षा।
> अंतिम अद्यतन: YYYY-MM-DD

## 1. परियोजना अवलोकन
- **व्यवसाय स्थिति**: मूल सिस्टम का नाम / सेवा प्राप्तकर्ता समूह / मुख्य लेनदेन प्रकार
- **महत्वपूर्ण श्रृंखला**: लेनदेन → जोखिम नियंत्रण → निपटान → मिलान → रिपोर्टिंग
- **अनुपलब्धता विंडो**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (इस अवधि में कोई भी परिवर्तन निषिद्ध)
- **मुख्य निर्भरताएँ**: अपस्ट्रीम <सिस्टम>, डाउनस्ट्रीम <सिस्टम>, नियामक रिपोर्टिंग प्लेटफ़ॉर्म

## 2. गैर-परक्राम्य सिद्धांत (रेड लाइन, उल्लंघन पर विलय अस्वीकृत)

### 2.1 सुरक्षा रेखाएं
- पासवर्ड, कुंजी और Token अनिवार्य रूप से KMS (की मैनेजमेंट सर्विस) से होकर गुज़रेंगे, **हार्डकोडिंग निषिद्ध**, **लॉग में मुद्रण निषिद्ध**
- ग्राहक संवेदनशील फ़ील्ड (आधार / कार्ड नंबर / CVV / मोबाइल नंबर) **एन्क्रिप्ट करके ही संग्रहीत किए जाएंगे**, सादा पाठ डेटाबेस में निषिद्ध
- लॉग में निषिद्ध हैं: पूरा आधार नंबर, पूरा कार्ड नंबर, सादा पाठ पासवर्ड, ग्राहक नाम + मोबाइल नंबर का संयोजन
- बाहरी इंटरफ़ेस कॉल अनिवार्य रूप से API गेटवे से होकर जाएंगे, सीधे कनेक्शन निषिद्ध

### 2.2 अनुपालन रेखाएं
- यदि AI-जनित कोड में ग्राहक डेटा तक पहुँच शामिल है, तो PR विवरण में "डेटा एक्सेस: <फ़ील्ड>" अंकित करना अनिवार्य है
- क्रॉस-बॉर्डर डेटा ट्रांसफर निषिद्ध, **सभी डेटा निर्यात के लिए सीमा पार डेटा स्थानांतरण मूल्यांकन प्रक्रिया (सीमा पार डेटा स्थानांतरण मूल्यांकन) अपनानी होगी** (अनुपालन विभाग से संपर्क करें)
- एल्गोरिदमिक निर्णय (क्रेडिट / बीमा मूल्य-निर्धारण / धोखाधड़ी-रोधी) में मानव समीक्षा का प्रवेश बिंदु अनिवार्य रूप से बनाए रखा जाएगा
- मॉडल परिवर्तन के लिए एल्गोरिदम पंजीकरण (एल्गोरिदम पंजीकरण) आवश्यक है, पंजीकरण संख्या PR विवरण में उद्धृत होनी चाहिए

### 2.3 व्यवसाय रेखाएं
- जोखिम नियंत्रण सीमा में परिवर्तन के लिए जोखिम प्रमुख + व्यवसाय प्रमुख की दोहरी हस्ताक्षर आवश्यक
- ग्राहक धन से जुड़े संचालन में idempotent डिज़ाइन + विफलता रोलबैक अनिवार्य
- लेनदेन सीमा, दरें और उत्पाद पैरामीटर में परिवर्तन पैरामीटर प्रबंधन प्लेटफ़ॉर्म से होकर जाएंगे, कोड में हार्डकोडिंग निषिद्ध

## 3. तकनीकी स्टैक और बाधाएं
- **भाषाएँ**: Java 17 (मूल) / Kotlin (नए मॉड्यूल) / SQL (डेटाबेस)
- **फ्रेमवर्क**: Spring Boot 3.x + Spring Cloud Alibaba
- **डेटाबेस**: OceanBase 4.x (MySQL संगत मोड), **विदेशी कुंजियों का उपयोग निषिद्ध**
- **इंटरफ़ेस मानक**: आंतरिक रूप से gRPC; बाहरी इंटरफ़ेस के लिए OpenAPI 3.0; RESTful केवल प्रशासनिक इंटरफ़ेस तक सीमित
- **नामकरण परंपरा**: Java क्लास PascalCase में, विधियाँ camelCase में, स्थिरांक UPPER_SNAKE में; तालिका नाम `t_<व्यवसाय डोमेन>_<इकाई>`; सूचकांक `idx_<तालिका>_<फ़ील्ड>_<क्रम>`
- **पैकेज संरचना**: `com.<कंपनी>.<व्यवसाय डोमेन>.<उप-डोमेन>.<स्तर>` (उदाहरण: `com.bank.pay.tx.core.service`)

## 4. कोड मानक
- **न्यूनतम परीक्षण कवरेज**: मूल श्रृंखला ≥ 80%, उपयोगिता वर्ग ≥ 60%, नए कोड PR में परीक्षण अनिवार्य
- **अनिवार्य परीक्षण पथ**: सभी controller में एकीकरण परीक्षण (विफलता पथ सहित) आवश्यक; सभी enum शाखाओं में यूनिट परीक्षण अनिवार्य
- **निषिद्ध पथ**: `<ऐतिहासिक बोझ मॉड्यूल>` निर्देशिका में संशोधन निषिद्ध — पहले अनुकूलन परत बनाई जानी चाहिए
- **निर्भरता प्रबंधन**: नई तृतीय-पक्ष निर्भरता के लिए SCA स्कैन + सुरक्षा अनुमोदन अनिवार्य

## 5. व्यवसाय नियम (डोमेन के अनुसार)
### 5.1 लेनदेन
- एकल लेनदेन सीमा: <राशि>; दैनिक सीमा: <राशि>; सीमा से अधिक होने पर मानव अनुमोदन अनिवार्य
- लेनदेन समय विंडो: <HH:MM> ~ <HH:MM>
- डुप्लिकेट लेनदेन निर्धारण: <समय विंडो> के भीतर समान <फ़ील्ड> डुप्लिकेट माना जाएगा

### 5.2 जोखिम नियंत्रण
- ब्लैकलिस्ट मिलान प्राथमिकता: आंतरिक ब्लैकलिस्ट → नियामक अधिसूचित सूची → न्यायिक फ्रीज़
- धोखाधड़ी-रोधी मॉडल आउटपुट सीमा: <स्कोर>; इससे अधिक होने पर मानव द्वितीय समीक्षा अनिवार्य

### 5.3 बिलिंग
- दर परिवर्तन में संस्करण संख्या + प्रभावी तिथि अनिवार्य
- ऐतिहासिक ऑर्डर प्रभावी तिथि पर लागू दर पर गणना किए जाएंगे, पूर्वव्यापी नहीं

## 6. अनुपालन आवश्यकताएं
- MLPS स्तर 3 (एक्विवेलेंट प्रोटेक्शन लेवल 3): <मूल्यांकन एजेंसी>, <अगले मूल्यांकन की तिथि>
- सीमा पार डेटा स्थानांतरण मूल्यांकन: लागू क्षेत्र (केवल क्रॉस-बॉर्डर व्यवसाय मॉड्यूल)
- एल्गोरिदम पंजीकरण: लागू क्षेत्र (क्रेडिट / बीमा मूल्य-निर्धारण जैसे प्रमुख एल्गोरिदम), पंजीकरण संख्या `<पंजीकरण संख्या>`
- नियामक रिपोर्टिंग: <CBIRC / चीन जनता बैंक> फ़ील्ड मैपिंग तालिका `<पथ>` में

## 7. AI उपयोग मानक
- **AI उपयोग की अनुमत परिदृश्य**: CRUD बॉयलरप्लेट, यूनिट परीक्षण जनरेशन, दस्तावेज़ मसौदा, SQL अनुकूलन सुझाव
- **मानव समीक्षा अनिवार्य परिदृश्य**: जोखिम नियंत्रण तर्क, बिलिंग नियम, अनुमति नियंत्रण, एन्क्रिप्शन / डिक्रिप्शन, क्रॉस-बॉर्डर डेटा
- **AI एकल रूप से निषिद्ध परिदृश्य**: Change Advisory Board (CAB) (परिवर्तन सलाहकार बोर्ड) अनुमोदन सामग्री, उत्पादन परिवर्तन निष्पादन, आपातकालीन प्रतिक्रिया
- **डेटा सीमा-पार नियम**: प्रशिक्षण डेटा / प्रॉम्प्ट / आउटपुट लॉग बाहर नहीं जाएंगे; स्थानीय परिनियोजन संस्करण (<विक्रेता>) को प्राथमिकता
- **ऑडिट आवश्यकता**: सभी AI-जनित कोड PR विवरण में "AI सहायता: <टूल का नाम>" अंकित होना चाहिए

## 8. विक्रेता शासन
- **विक्रेता प्रवेश**: SOC 2 / ISO 27001 रिपोर्ट प्रदान करना अनिवार्य; AI मॉडल के लिए मॉडल कार्ड अनिवार्य
- **अनुबंध शर्तें**: डेटा स्वामित्व, मॉडल व्याख्यायिता, निकास शर्तें, ऑडिट अधिकार
- **ऑडिट तंत्र**: त्रैमासिक विक्रेता AI उपयोग ऑडिट; उच्च-जोखिम विक्रेता के लिए मासिक ऑडिट

## 9. शासन और अद्यतन
- **स्वामी**: <शासन समिति> (अनुपालन + सुरक्षा + आर्किटेक्चर + व्यवसाय)
- **अद्यतन आवृत्ति**: त्रैमासिक समीक्षा; आपातकालीन परिवर्तन के लिए त्वरित मार्ग (दोहरी हस्ताक्षर + 24h प्रकाशन)
- **परिवर्तन लॉग**: देखें `CLAUDE_CHANGELOG.md`
- **उल्लंघन प्रबंधन**: पहला उल्लंघन = चेतावनी + अनिवार्य प्रशिक्षण; दूसरा उल्लंघन = AI टूल उपयोग निलंबित; तीसरा = अधिकार निरस्त

यह ढांचा “मानक उत्तर” नहीं है, बल्कि “भरने का टेम्पलेट” है। हर खाली जगह में क्या भरा जाए, यह इससे कहीं ज़्यादा महत्वपूर्ण है कि कितना लिखा गया है—जो हिस्से खाली रह जाते हैं, वे आपकी कंपनी के उन पहलुओं को उजागर करते हैं जिनके बारे में अभी स्पष्टता नहीं है।

एक विशिष्ट उदाहरण: HDFC जैसे एक प्रमुख भारतीय निजी बैंक के CLAUDE.md में पासवर्ड हैंडलिंग के लिए विशेष नियम परिभाषित किए गए थे—AI द्वारा जनरेट किया गया कोड, जब भी पासवर्ड से जुड़ा हो, उसे आंतरिक HSM (Hardware Security Module) API को कॉल करना अनिवार्य है, hardcoding पूरी तरह प्रतिबंधित है। इस तरह के नियम RBI साइबर सुरक्षा फ्रेमवर्क और DPDP Act 2023 के अनुपालन समीक्षा में अस्वीकृति के कारणों में बहुत बड़ा हिस्सा रखते हैं।

2026 H1 का एक महत्वपूर्ण नया तत्व Skills/कार्यप्रवाह परिभाषा है—यह सिर्फ़ दस्तावेज़ नहीं, बल्कि एक टूलचेन है जिसे AI द्वारा कॉल किया जा सकता है। Claude Code का Skills सिस्टम (फरवरी 2026 में Anthropic के आधिकारिक मार्केटप्लेस में आया, GitHub पर 11.2 लाख stars) “Excel शीट पढ़ना”, “SQL जनरेट करना”, “डेटा माइग्रेशन चलाना” जैसे कार्यों को साझा करने योग्य वर्कफ़्लो में बदल देता है। यही 2026 H1 में मानक-संचालित दृष्टिकोण की प्रमुख उन्नति है: मानक केवल बाधाएँ नहीं हैं, बल्कि निष्पादन योग्य वर्कफ़्लो हैं।

तीसरा चरण: संस्थागतकरण (निरंतर)।

स्पेक लिख देना अंत नहीं है, यह शुरुआत है। आपको इसे संगठन की प्रक्रिया का हिस्सा बनाना होगा:

  • CI गेटिंग इंटीग्रेशन: स्वचालित रूप से जाँच करें कि कोड स्पेक का पालन करता है या नहीं (जैसे पासवर्ड हार्डकोडिंग, संवेदनशील फ़ील्ड का एन्क्रिप्ट न होना)
  • टीम-शेयर्ड कॉन्फ़िगरेशन: Skills सिस्टम के ज़रिए पूरी टीम एक ही स्पेक का उपयोग करे
  • नियमित अपडेट मैकेनिज़्म: नियम बदले, तो स्पेक भी बदलना चाहिए (त्रैमासिक समीक्षा)
  • मेट्रिक्स और फीडबैक: AI कोड की डिफेक्ट दर, कंप्लायंस रिव्यू पास दर, रीवर्क दर ट्रैक करें
  • एजेंट गवर्नेंस: मानव गवर्नेंस को AI एजेंट्स तक विस्तारित करें — Atos ने Agent 365 पर यही किया है, इसे “सिस्टम-लेवल” बनाया, “व्यक्तिगत-लेवल” नहीं

EY और Atos ने 2026 H1 में तीसरे चरण को “संगठनात्मक क्षमता” बनाया। EY की 2.5 मिलियन घंटे की बचत पहले और तीसरे चरण को सही ढंग से करने की देन है — दूसरा चरण सिर्फ़ नियमों को AI-पठनीय दस्तावेज़ में बदलना था।

पाँच: सख्त रेगुलेशन वाला वेरिएंट: कंप्लायंस एम्बेड करने के तीन इंजीनियरिंग तरीके

फाइनेंस, टेलीकॉम, हेल्थकेयर जैसे सख्त रेगुलेशन वाले उद्योगों में, स्पेक-ड्रिवन इम्प्लीमेंटेशन में सामान्य उद्योगों की तुलना में एक अतिरिक्त बाधा होती है — कंप्लायंस प्रोसेस का बाहरी ऐड-ऑन नहीं है, यह कोड में बिल्ट-इन होता है। नीचे तीन तरीके 2026 H1 में सत्यापित कंप्लायंस एम्बेडिंग के तरीके हैं, जिन्हें CIO/डिजिटल हेड संगठनात्मक डिज़ाइन करते समय सीधे संदर्भ में ले सकते हैं।

5.1 स्ट्रीम टीम में एम्बेडेड कंप्लायंस रिप्रेजेंटेटिव: कंप्लायंस को “मंज़ूरी” नहीं, “मौजूदगी” बनाएं

पुराना तरीका: बिज़नेस टीम कोड लिखती है, कंप्लायंस टीम बाद में ऑडिट करती है—जब तक ऑडिट में समस्या पकड़ में आती है, कोड प्रोडक्शन में आधे महीने पहले जा चुका होता है, और दोबारा काम करने में 2-4 हफ्ते लग जाते हैं। असली समस्या यह है कि कंप्लायंस प्रोसेस के सबसे आखिरी छोर पर बैठा है।

नया तरीका: हर स्ट्रीम-अलाइन्ड टीम में एक कंप्लायंस रिप्रेजेंटेटिव एम्बेड करें, जिसमें “सॉलिड लाइन कंप्लायंस डिपार्टमेंट को, डॉटेड लाइन बिज़नेस टीम को” रिपोर्ट करने का दोहरा ढांचा हो। डिज़ाइन इस तरह:

  • हेडकाउंट: हर 6-8 स्ट्रीम टीम पर 1 कंप्लायंस रिप्रेजेंटेटिव, जो कंप्लायंस डिपार्टमेंट में पेरोल पर हो लेकिन फिज़िकली बिज़नेस टीम के साथ बैठे—यह “ऑन-डिपार्टमेंट डेपुटेशन” नहीं है
  • डॉटेड-लाइन KPI: कंप्लायंस रिप्रेजेंटेटिव का 50% वेटेज बिज़नेस टीम के “कंप्लायंस डिफेक्ट रेट” और “फर्स्ट-पास रिव्यू रेट” पर टिका हो, न कि सिर्फ कंप्लायंस डिपार्टमेंट के “ऑडिट कवरेज” पर
  • शुरुआती दखल: कंप्लायंस रिप्रेजेंटेटिव डेली स्टैंडअप (हफ्ते में 1 बार काफी है), PR रिव्यू में शामिल हो, और AI-जनरेटेड कोड को मर्ज होने से पहले कंप्लायंस रिप्रेजेंटेटिव से पास कराना अनिवार्य हो—मर्ज के बाद पकड़े जाने का इंतज़ार नहीं
  • टूल सपोर्ट: कंप्लायंस रिप्रेजेंटेटिव चेकलिस्ट के लिए Skills-आधारित कॉल का उपयोग करें, न कि मैन्युअल रूप से हर आइटम मिलाना

विशिष्ट परिदृश्य: SBI जैसे किसी बड़े भारतीय सार्वजनिक क्षेत्र के बैंक ने 2026 की पहली छमाही में 3 स्ट्रीम टीमों में कंप्लायंस प्रतिनिधियों को शामिल करके पायलट प्रोजेक्ट चलाया, जिससे AI कोड कंप्लायंस अस्वीकृति दर 35% से घटकर 8% हो गई — मूल बात यह नहीं है कि कंप्लायंस “अधिक सख्ती से” देखता है, बल्कि यह है कि कंप्लायंस “पहले” देखता है। इस दृष्टिकोण की कुंजी यह है कि कंप्लायंस प्रतिनिधियों का डॉटेड-लाइन प्रोत्साहन व्यावसायिक लक्ष्यों के साथ संरेखित हो — यदि कंप्लायंस प्रतिनिधियों का KPI अभी भी केवल कंप्लायंस विभाग द्वारा दिए गए कार्यों पर आधारित है, तो एम्बेडिंग विफल है।

5.2 कंप्लायंस को enabling team बनाना: बाधाओं को affordance में बदलना

पारंपरिक दृष्टिकोण: कंप्लायंस टीम “गेटकीपर” है, और व्यावसायिक टीम कंप्लायंस को “परेशानी पैदा करने वाला” मानती है। दोनों पक्षों के बीच जीरो-सम गेम होता है।

नया दृष्टिकोण: कंप्लायंस टीम को Team Topologies के enabling team मॉडल के अनुसार पुनर्गठित किया गया है — यह सीधे कोड नहीं लिखती, सीधे PR की समीक्षा नहीं करती, लेकिन तीन चीज़ें प्रदान करती है जिससे व्यावसायिक टीमें “स्वयं-कंप्लायंस” कर सकें:

  1. CI पाइपलाइन में अनुपालन जाँच: पासवर्ड हार्डकोडिंग, संवेदनशील फ़ील्ड का प्लेनटेक्स्ट, क्रॉस-बॉर्डर डेटा ट्रांसफ़र, और एल्गोरिदमिक निर्णय बिंदु जैसे उच्च-आवृत्ति अनुपालन मुद्दों को GitHub Actions / GitLab CI में अनिवार्य गेट के रूप में लागू करें। बिज़नेस टीम के PR पर स्वचालित जाँच चलती है, और गैर-अनुपालन पर सीधे fail — अनुपालन प्रतिनिधि को मैन्युअल रूप से सब कुछ जाँचने की ज़रूरत नहीं।

  2. नियामक आवश्यकताओं को affordance (पर्यावरण-संवेदनशील बाधा) के रूप में डिज़ाइन करें: उदाहरण के लिए, ग्राहक डेटा से जुड़ी सुविधा विकसित करते समय, IDE प्लगइन “इस फ़ील्ड के लिए KMS कॉल करने की सलाह दी जाती है” का संकेत दिखाए; लॉग लिखते समय स्वचालित रूप से पता लगाए कि उसमें संवेदनशील जानकारी है या नहीं और अलर्ट करे। अनुपालन आवश्यकता को “डेवलपमेंट के दौरान स्वाभाविक रूप से होने वाली क्रिया” बनाएं, न कि “लॉन्च से पहले बताया जाए कि क्या उल्लंघन हुआ”।

  3. साझा Skills लाइब्रेरी + अनुपालन प्रशिक्षण: अनुपालन टीम एक “अनुपालन Skills” संग्रह बनाए रखती है, जिसे नए कर्मचारी ज्वाइन करने या क्रॉस-टीम ट्रांसफ़र पर सीधे उपयोग कर सकते हैं — अनुपालन ज्ञान को “दस्तावेज़” से “निष्पादन योग्य टूल” में बदलें।

विशिष्ट परिदृश्य: एक क्षेत्रीय बैंक ने 2026 H1 में CI अनुपालन गेट + IDE अनुपालन संकेत लॉन्च किए, जिससे AI कोड अनुपालन समीक्षा का औसत समय 45 मिनट/बार से घटकर 8 मिनट/बार हो गया। **मुख्य बात यह नहीं है कि अनुपालन “समीक्षा तेज़” हुई, बल्कि AI जनरेशन के समय ही “गलती नहीं होती”**।

5.3 दोहरी-गति अनुपालन: व्यावसायिक गति के अनुसार परत-दर-परत मिलान

अंतिम विवरण: अनुपालन (compliance) में “एक ही पैमाना” नहीं होना चाहिए। नियमों को जोखिम स्तर के आधार पर दो श्रेणियों में बाँटें:

  • उच्च-जोखिम नियम (ग्राहक के फंड / एल्गोरिदमिक निर्णय / क्रॉस-बॉर्डर डेटा / सुरक्षा मूल्यांकन की लाल रेखाएँ) → सख्त गेटिंग: अनिवार्य मानव समीक्षा + AI द्वारा दूसरी पुष्टि + Change Advisory Board (CAB) (Change Advisory Board) में पंजीकरण
  • निम्न-जोखिम नियम (CRUD टेम्पलेट / टूल-आधारित कोड / दस्तावेज़ जनरेशन) → सेल्फ-सर्विस गेटिंग: केवल CI स्वचालित जाँच पर्याप्त है, मानव समीक्षा की आवश्यकता नहीं

Atos का Agent 365 कंट्रोल प्लेन मूल रूप से इसी स्तरीकरण पर आधारित है—विभिन्न स्तरों के एजेंट अलग-अलग गवर्नेंस आवश्यकताओं से बंधे होते हैं। अनुपालन नियमों को जोखिम स्तर के अनुसार विभाजित करने से बिज़नेस टीम को यह महसूस होता है कि “अनुपालन हर कदम पर रोड़ा नहीं है।”

इन तीनों बातों को एक साथ देखने पर निष्कर्ष: अनुपालन को एम्बेड करना कोई अतिरिक्त प्रक्रिया जोड़ना नहीं है, बल्कि टीम की संरचना और प्रोत्साहन (incentives) को फिर से डिज़ाइन करना है। यदि आपका अनुपालन विभाग अभी भी “पोस्ट-हॉक समीक्षा” मोड में है, तो स्पेक-ड्रिवन (spec-driven) कार्यान्वयन सबसे कठिन “संस्थागतकरण” वाले चरण में अटक जाएगा—अनुपालन विभाग को पहले खुद को बदलना होगा, तभी बिज़नेस टीम का स्पेक-ड्रिवन वर्कफ़्लो सुचारू रूप से चल पाएगा।

छह: आपके मन में शायद ये सवाल हों

“हमारे पास पहले से कोडिंग स्टैंडर्ड हैं, इसमें क्या अलग है?”

कोडिंग स्टैंडर्ड यह तय करते हैं कि “कोड कैसे लिखा जाए”, जबकि स्पेक-ड्रिवन यह तय करता है कि “AI के साथ सहयोग कैसे किया जाए”। कोडिंग स्टैंडर्ड में ये शामिल नहीं होते: बिज़नेस नियम, अनुपालन आवश्यकताएँ, AI उपयोग नीतियाँ। स्पेक-ड्रिवन “मानव और AI के सहयोग की पूरी प्रक्रिया” को स्पष्ट रूप से परिभाषित करता है—यह कोड-स्टाइल गाइड नहीं है।

“क्या स्टैंडर्ड लिखने से डेवलपमेंट की स्पीड कम हो जाती है?”

थोड़े समय में हाँ, लंबे समय में नहीं। CodeRabbit का डेटा स्पष्ट जवाब देता है: बिना किसी बाधा वाले AI कोड में डिफेक्ट का जोखिम लगभग 1.7 गुना और सिक्योरिटी कमजोरियों का जोखिम 2.74 गुना अधिक होता है। फाइनेंशियल सेक्टर में, एक कंप्लायंस रिव्यू का रीवर्क 2-4 हफ्ते लेता है—एक बार का रीवर्क बचाना ही काफी है, उस समय में आप एक महीने के स्टैंडर्ड लिख सकते हैं। EY का 2.5 करोड़ डॉलर का बचत, इस बात का असली सबूत है कि इसे ऑर्गनाइजेशनल कैपेबिलिटी बनाना कितना फायदेमंद है।

“हमारी टीम में कोई स्टैंडर्ड लिखना नहीं जानता, तो क्या करें?”

आपको शून्य से शुरू करने की जरूरत नहीं है। GitHub Spec Kit, Claude Code Superpowers, और AWS Kiro सभी में टेम्पलेट मौजूद हैं। आपको बस अपने ऑर्गनाइजेशन के लिए खास नियम भरने हैं—जिनमें से ज्यादातर कंप्लायंस और सिक्योरिटी से जुड़े होते हैं, और ये नियम आपके कंप्लायंस और सिक्योरिटी विभागों ने पहले ही लिख रखे हैं, बस उन्हें AI की पहुंच में नहीं रखा गया है।

“AI टूल्स इतने सारे हैं, किसे चुनें?”

महत्वपूर्ण नहीं है। जो आप पहले से उपयोग कर रहे हैं, उसे चुनें। नियम-संचालित, टूल-अनिर्भर—CLAUDE.md Claude Code, Cursor और Codex में काम करता है; AGENTS.md OpenAI इकोसिस्टम में चलता है; constitution.md मॉडल-अनिर्भर है। असली बात नियम लिखना है, टूल बदलना नहीं। EY Microsoft इकोसिस्टम में तैनाती कर रहा है, Atos भी Microsoft इकोसिस्टम में तैनाती कर रहा है—टूल का चुनाव सिर्फ सतही अंतर है, गवर्नेंस आर्किटेक्चर की एकरूपता ही असली नींव है।

“अगस्त 2026 में EU AI Act पूरी तरह लागू हो जाएगा—क्या इसका हम पर असर पड़ेगा?”

हाँ। EU AI Act अगस्त 2026 में पूर्ण रूप से लागू हो चुका है, और उच्च-जोखिम वाली AI प्रणालियों (जिनमें क्रेडिट, बीमा मूल्य-निर्धारण, रोजगार स्क्रीनिंग, और महत्वपूर्ण बुनियादी ढाँचा शामिल हैं) के लिए अनिवार्य अनुपालन आवश्यकताएँ निर्धारित करता है — जोखिम प्रबंधन (Art. 9), डेटा गवर्नेंस (Art. 10), दस्तावेज़ीकरण और पारदर्शिता (Art. 11-13), मानवीय निगरानी (Art. 14), और सटीकता/मजबूती (Art. 15)। उल्लंघन पर अधिकतम जुर्माना €35 मिलियन या वैश्विक राजस्व का 7% तक हो सकता है। चीनी कंपनियों के लिए जो विदेशों में विस्तार कर रही हैं, EU बाजार एक अनिवार्य परीक्षा है; घरेलू कंपनियों के लिए भी, EU AI Act का ढाँचा वैश्विक स्तर पर सबसे अधिक संदर्भित मानक बन गया है — आप सीधे इसके अधीन नहीं आ सकते, लेकिन आपके आपूर्तिकर्ताओं, साझेदारों और सीमा-पार व्यवसाय पर इसके अप्रत्यक्ष प्रभाव को नज़रअंदाज़ करना मुश्किल है (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6)।

“घरेलू तुलना: EU AI को नियंत्रित करता है, हम क्या नियंत्रित करते हैं?”

घरेलू स्तर पर, जनरेटिव AI के शासन के लिए तीन-आयामी दृष्टिकोण अपनाया गया है: “एल्गोरिदम पंजीकरण + कॉर्पस समीक्षा + सुरक्षा मूल्यांकन।” अगस्त 2023 में लागू हुआ “जनरेटिव आर्टिफिशियल इंटेलिजेंस सर्विसेज मैनेजमेंट के लिए अंतरिम उपाय” इसका मुख्य आधार है। दोनों के बीच सबसे बड़ा अंतर प्रावधानों की बारीकियों में नहीं है, बल्कि विधायी दर्शन में है:

आयामEU AI Actचीन का “जनरेटिव AI सेवा प्रबंधन उपाय”
कानूनी स्थितिक्षैतिज विनियमन (सभी AI सिस्टम पर लागू)ऊर्ध्वाधर नियम (केवल जनरेटिव AI सेवाओं पर केंद्रित)
जोखिम वर्गीकरण4 स्तर (अस्वीकार्य / उच्च / सीमित / न्यूनतम)2 स्तर (जनमत सुरक्षा से संबंधित / सामान्य वाणिज्यिक)
विनियामक समय-बिंदुपूर्व-निर्धारित (विकास के समय ही पंजीकरण)पश्च-निर्धारित (लॉन्च के बाद पंजीकरण + एल्गोरिदम पंजीकरण)
पारदर्शिताउच्च (प्रशिक्षण डेटा स्रोत सारांश और मॉडल कार्ड का खुलासा अनिवार्य)मध्यम (डेटा स्रोतों का अनुपालन आवश्यक, लेकिन स्रोतों का खुलासा अनिवार्य नहीं)
दंड की अधिकतम सीमावैश्विक राजस्व का 7% या €35 मिलियनसेवा निलंबन / जुर्माना (आमतौर पर अवैध लाभ का गुणक)
लागू दायरावैश्विक राजस्व सीमा के भीतर सभी उद्यमचीन के क्षेत्र में सेवाएं प्रदान करने वाले सभी संस्थाएं

सातवाँ: निर्णयकर्ताओं के लिए सीख

सीख 1: CLAUDE.md/AGENTS.md प्रोजेक्ट स्पेसिफिकेशन लिखना, AI युग में सबसे अधिक ROI वाला इंजीनियरिंग कदम है।

व्यवहार में, भारतीय वित्तीय संस्थानों की AI प्रणालियाँ आमतौर पर तीन स्तरों के नियमों के अधीन होती हैं — DPDP Act 2023 + DPDP Rules 2025 (व्यक्तिगत डेटा संरक्षण परत) + CERT-In Directions 2022 (साइबर सुरक्षा इन्सिडेंट रिपोर्टिंग परत) + RBI की बैंकिंग दिशानिर्देश + MeitY Digital India Act (ड्राफ्ट) के तहत एल्गोरिदम पंजीकरण (अनुपालन परत)। इसका मतलब है कि भारत में नियम-संचालित दृष्टिकोण अपनाते हुए, EU AI Act के ढाँचे की नकल नहीं की जा सकती — CLAUDE.md में भारतीय “DPDP Act अनुपालन + CERT-In घटना रिपोर्टिंग + MeitY एल्गोरिदम पंजीकरण” तीनों रेखाओं को शामिल करना होगा।

वैश्विक स्तर पर जाने वाली कंपनियों के लिए: EU AI Act का “जोखिम प्रबंधन + डेटा गवर्नेंस + दस्तावेज़ पारदर्शिता + मानव पर्यवेक्षण” चौगुना सेट, वही दिशा है जिसकी ओर भारतीय नियमन भी धीरे-धीरे संरेखित हो रहा है — 2025-2026 में MeitY की कई जनरेटिव AI पंजीकरण प्रतिक्रियाएँ पहले ही EU की बारीकी (ग्रैन्युलैरिटी) को अपना चुकी हैं। आज EU AI Act-संगत नियम लिखना, अगले 3 वर्षों में संभवतः भारतीय कड़े नियमन के साथ भी संगत रहेगा (MeitY डिजिटल इंडिया एक्ट ड्राफ्ट 2025-2026; EU AI Act अनुपालन 2026.6)।

इसका निवेश 3-8 सप्ताह का व्यवस्थितकरण समय + 1-2 सप्ताह का दस्तावेज़ीकरण समय है। इसका प्रतिफल है: दोष जोखिम सीमा लगभग 1.7 गुना कम, सुरक्षा कमज़ोरियों में 2.74 गुना कमी, और रीवर्क दर में 40%+ की गिरावट। वित्तीय क्षेत्र में, एक बार की अनुपालन समीक्षा रीवर्क (2-4 सप्ताह) बचाने मात्र से यह लागत वसूल हो जाती है। EY ने 150,000 कर्मचारियों के लिए Copilot तैनात कर $250 मिलियन बचाए—लेकिन शर्त यह थी कि पहले से मानक परिभाषित थे।

निष्कर्ष दो: मानक-संचालित दृष्टिकोण एक संगठनात्मक क्षमता है, कोई टूल चयन नहीं।

आप GitHub Spec Kit चुनें या Claude Code—यह महत्वपूर्ण नहीं है। महत्वपूर्ण यह है कि क्या आपने परिभाषित किया है कि “हमारा संगठन AI के साथ कैसे सहयोग करता है।” इसके बिना, कोई भी बेहतरीन टूल केवल टीम को और तेज़ी से और अधिक तकनीकी ऋण बनाने में मदद करेगा।

निष्कर्ष तीन: मानकों को संगठनात्मक प्रक्रियाओं में लिखें, व्यक्तिगत निर्भरता पर नहीं छोड़ें।

यदि मानक केवल किसी वरिष्ठ इंजीनियर के दिमाग में मौजूद हैं, तो कर्मचारी के जाने पर वे खो जाते हैं। उन्हें रिपॉजिटरी दस्तावेज़ों, CI गेट्स, टीम-साझा कॉन्फ़िगरेशन और एजेंट गवर्नेंस प्लेटफ़ॉर्म में समाहित करना आवश्यक है। मानकों को संगठनात्मक संपत्ति बनाएं, व्यक्तिगत कौशल नहीं। Atos के 19,000 एजेंट 54 देशों में काम करते हैं, क्योंकि गवर्नेंस “किसी व्यक्ति की समझ” नहीं है—यह “सिस्टम द्वारा अनिवार्य” है।

निष्कर्ष चार: गेटिंग गति से अधिक महत्वपूर्ण है।

GitHub Spec Kit की पाँच-चरणीय गेटिंग प्रक्रिया, Superpowers का “टेस्ट फेल होने से पहले कोड मत लिखो” सिद्धांत, और Kiro का “बिना spec लिखे प्रोजेक्ट शुरू ही नहीं होगा” — ये सभी AI और अंतिम आउटपुट के बीच एक “ब्रेक” लगाते हैं। AI की क्षमता जितनी बढ़ती है, गवर्नेंस उतनी ही पहले से लागू होनी चाहिए। New Relic की 2026 रिपोर्ट में बताया गया 78% इंसीडेंट रेट, उन 62% टीमों की कीमत है जो “बिना रिव्यू किए डिप्लॉय” कर देती हैं। फाइनेंशियल सेक्टर के CIO इस बात को सबसे अच्छी तरह समझते हैं: आपकी Change Advisory Board (Change Advisory Board (CAB)), RBI की नियामक अनुमोदन प्रक्रिया, DPDP Act 2023 के तहत डेटा संरक्षण बोर्ड (DPB) की समीक्षा, और CERT-In Directions 2022 के तहत 6-घंटे की साइबर घटना रिपोर्टिंग — ये सब प्रोडक्शन से पहले गेटिंग करते हैं। AI-जनरेटेड कोड को भी ऐसी ही गेटिंग चाहिए, और वह भी और पहले से।

रिवर्स सेल्फ-चेक (जवाब देते समय कोई सुधार-परिवर्तन न करें): क्या आपकी AI-जनरेटेड कोड की कंप्लायंस रिव्यू में अक्सर दोबारा काम करना पड़ता है? आखिरी बार AI-जनरेटेड कोड से कोई प्रोडक्शन इश्यू कब आया? अगर आप अपने टेक्निकल हेड से पूछें “हम AI के साथ कैसे काम करते हैं”, तो क्या वे एक दस्तावेज़ दिखा सकते हैं? इन तीनों में से एक का भी जवाब न दे पाएँ, तो समझिए कि स्पेक-ड्रिवन अप्रोच अभी लागू नहीं हुई है — पहले स्पेक लिखिए, फिर टूल खरीदिए।

निर्णयकर्ताओं के लिए तीन कोचिंग प्रश्न

अंत में तीन सवाल — ये कोई चेकलिस्ट नहीं है, बल्कि सीधे आपकी टीम के साथ चर्चा में इस्तेमाल करने के लिए हैं:

  1. “यदि कल सभी AI टूल बंद हो जाएँ, तो आपकी टीम की कोड गुणवत्ता में कितनी गिरावट आएगी?” — यह सवाल वास्तव में स्पेक-ड्रिवन (spec-driven) दृष्टिकोण के असली मूल्य को उजागर करता है: यदि उत्तर है “काफी गिरावट”, तो इसका मतलब है कि आपके स्पेक्स अभी तक टीम में आत्मसात नहीं हुए हैं; यदि उत्तर है “लगभग कोई बदलाव नहीं”, तो स्पेक-ड्रिवन प्रक्रिया पहले से चल रही है।

  2. “आपके स्पेक-ड्रिवन प्रोजेक्ट में कंप्लायंस विभाग की भूमिका क्या है — ‘गेटकीपर’ या ‘enabler’?” — यदि उत्तर “गेटकीपर” है, तो आपकी डिलीवरी स्पीड रिव्यू बॉटलनेक में फँस जाएगी; यदि उत्तर “enabler” है, तो आप सेक्शन 5.2 के सही रास्ते पर हैं।

  3. “12–18 महीनों में आपकी टीम का आकार कैसे बदलेगा?” — Microsoft WTI 2026 का उत्तर यह है कि 82% नेता AI एजेंट्स के माध्यम से अपनी workforce को “स्केल” करेंगे। यदि आपका उत्तर “कोई बदलाव नहीं” है, तो या तो आपका बिज़नेस बढ़ नहीं रहा है, या आपका संगठनात्मक डिज़ाइन स्पेक-ड्रिवन के लाभों को अपना नहीं पा रहा है।

इन तीनों सवालों का कोई एक “सही” उत्तर नहीं है। लेकिन उत्तर की दिशा, उत्तर से अधिक महत्वपूर्ण है।

अगला कदम

यह “AI युग में सॉफ्टवेयर इंजीनियरिंग का बदलाव” श्रृंखला का छठा लेख है। Conway के नियम (संगठन आर्किटेक्चर तय करता है) से शुरू करके Team Topologies (संगठन को कैसे डिज़ाइन करें) तक, फिर बॉटलनेक शिफ्ट (बॉटलनेक कोडिंग में नहीं, वैलिडेशन में है) पर चर्चा की, और आज स्पेक-ड्रिवन (दस्तावेज़ों के माध्यम से AI व्यवहार को नियंत्रित करना) पर पहुँचे हैं।

अगले भाग (सातवाँ) में, हम उस अंतर्निहित बुनियादी ढांचे को देखेंगे जो इन सबको संभव बनाता है — **MCP प्रोटोकॉल (Model Context Protocol)**। यह समझेंगे कि Anthropic द्वारा ओपन-सोर्स किया गया यह प्रोटोकॉल “AI का USB-C” क्यों कहलाता है, OpenAI, Google और Microsoft सभी ने इसे क्यों अपनाया, और यह किस तरह कई टूल्स और कई एजेंट्स के आपसी इंटरऑपरेशन को संभव बनाता है।

इन नियमों को अपनी कंपनी में लागू करना चाहते हैं?

जब नियम-संचालित (spec-driven) दृष्टिकोण किसी उद्यम में पहुँचता है, तो असल में कुछ ही ठोस सवाल हल करने होते हैं: मुख्य नियमों को CLAUDE.md / AGENTS.md में कैसे समेटा जाए, पुराने कोड में ये नियम कैसे जोड़े जाएँ, अनुपालन (compliance) को वर्कफ़्लो में कैसे शामिल किया जाए, और पायलट प्रोजेक्ट की सफलता किन मेट्रिक्स से मापी जाए।

फ़िलहाल तीन तरह के सहयोग उपलब्ध हैं:

  • एंटरप्राइज़ ट्रेनिंग: आपकी कंपनी के वास्तविक प्रोजेक्ट्स के आधार पर, स्पेक दस्तावेज़ तैयार करना, CI गेटिंग डिज़ाइन करना, अनुपालन एम्बेड करने का रास्ता और गवर्नेंस तंत्र स्थापित करना।
  • विशेष परामर्श: एक स्पष्ट निर्णय पर केंद्रित, जैसे “क्या हमें पहले CLAUDE.md / AGENTS.md लिखना चाहिए?” या पुराने कोड के अनुपालन सुधार की प्राथमिकता तय करना।
  • प्रबंधन के लिए प्रस्तुति और उद्योग वार्ता: AI कोडिंग टूल्स, नियम-संचालित विकास, संगठनात्मक गवर्नेंस और Frontier Firms पर केंद्रित।

यह लेख एक सामान्य रूपरेखा प्रदान कर सकता है। वास्तविक कार्यान्वयन के लिए कंपनी की अनुपालन आवश्यकताओं, नियामक सीमाओं, इंजीनियरिंग परिपक्वता और मौजूदा डिलीवरी प्रक्रियाओं के आधार पर पुनः डिज़ाइन की आवश्यकता होती है। सहयोग के लिए coach@iaiuse.com पर संपर्क किया जा सकता है।

आगे पढ़ें: 《साइनबोर्ड पद्धति v1.0》(धीरे-धीरे AI सीखें 187), जो एंटरप्राइज़ AI परिवर्तन के लिए 7-चरणीय ढांचे का व्यवस्थित परिचय देता है।

इस श्रृंखला के बारे में

“AI युग में सॉफ्टवेयर इंजीनियरिंग परिवर्तन” दूरसंचार, वित्त, विनिर्माण, ई-कॉमर्स आदि उद्योगों के CIO, CDO, CTO और डिजिटल प्रभारियों के लिए एक शोध श्रृंखला है, जिसमें 18 लेख शामिल हैं। यह श्रृंखला मुख्य रूप से चर्चा करती है कि AI कोडिंग टूल, स्पेसिफिकेशन-संचालित विकास और संगठनात्मक शासन सॉफ्टवेयर डिलीवरी प्रक्रियाओं, संगठनात्मक संरचना और इंजीनियरिंग परिपक्वता को कैसे प्रभावित करते हैं।

यह श्रृंखला लगातार शैक्षणिक शोधपत्रों, विक्रेता सामग्रियों और उद्योग रिपोर्टों पर नज़र रखती है। शोध डेटाबेस में 200 से अधिक दस्तावेज़ संचित हैं, और प्रमुख निष्कर्षों के लिए साक्ष्य स्तर अंकित किए गए हैं, जिससे सत्यापित तथ्यों, विक्रेता दावों, उद्योग टिप्पणियों और लेखक के अनुमानों के बीच स्पष्ट अंतर किया जा सके।

मेरे पास लगभग 8 वर्षों का बड़े उद्यमों में परामर्श और व्यावसायिक विश्लेषण का अनुभव है। मैंने IBM में कार्य किया है और दूरसंचार, वित्त, बीमा और विनिर्माण से संबंधित परियोजनाओं में भाग लिया है। इसके बाद, मैंने ऑपरेटर उत्पादों, इंटरनेट उत्पादों और AI एप्लिकेशन विकास के क्षेत्र में आवश्यकता विश्लेषण, उत्पाद डिज़ाइन और क्रॉस-टीम कार्यान्वयन पर काम करना जारी रखा है।

यह श्रृंखला मानक-संचालित, संगठनात्मक शासन और इंजीनियरिंग-केंद्रित निर्णयों पर जो कुछ कहती है, वह इन्हीं व्यावहारिक अनुभवों से आता है, और इसे सार्वजनिक शोध तथा उद्योग केस स्टडीज़ से क्रॉस-वेरिफाई किया गया है। विशिष्ट प्रोजेक्ट्स से जुड़ी सामग्री को पूरी तरह अनामीकृत (anonymized) किया गया है; कुछ उद्योग परिदृश्य विशिष्ट समस्याओं के तार्किक अनुमान हैं, जिनके आधार अंत में दिए गए संदर्भ स्रोतों में देखे जा सकते हैं।

यह अकाउंट असल में एक छोटी टीम चलाती है — मैं और 1-2 दीर्घकालिक सहयोगी, जो अलग-अलग ज़िम्मेदारियाँ संभालते हैं: AI कोडिंग टूल्स पर शोध, संगठनात्मक शासन के केस स्टडीज़, और कोचिंग संवाद। लेख में जिन प्रोजेक्ट्स का ज़िक्र है कि “हमने कंपनियों के साथ मिलकर यह रास्ता तय किया,” उनमें से अधिकांश हमने मिलकर डिलीवर किए हैं। ग्राहकों की कंप्लायंस सीमाओं और व्यक्तियों के नामों का उल्लेख नहीं किया जाएगा; अनामीकरण बनाए रखा गया है ताकि भविष्य के सहयोगियों के लिए जगह बनी रहे।

संदर्भ स्रोत (सभी सत्यापित, प्रत्येक में साक्ष्य का स्तर दर्शाया गया है)

  • CodeRabbit (2025.12). State of AI vs Human Code Generation Report. AI द्वारा लिखे गए कोड में मानव-निर्मित कोड की तुलना में 1.7 गुना अधिक समस्याएँ पाई गईं (10.83 बनाम 6.45 समस्याएँ प्रति PR)। तर्क/शुद्धता में 1.75×, कोड गुणवत्ता में 1.64×, सुरक्षा में 1.57×, पासवर्ड हैंडलिंग में 1.88×, और XSS में 2.74× अधिक समस्याएँ। साक्ष्य स्तर: प्रथम श्रेणी। स्रोत: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263

  • The Register (2025.12.17). CodeRabbit रिपोर्ट की पूरी कवरेज: 470 ओपन-सोर्स PR का विश्लेषण, AI-सहयोग वाले PR में 10.83 समस्याएँ बनाम पूर्णतः मानव-निर्मित PR में 6.45 समस्याएँ। साक्ष्य स्तर: द्वितीय श्रेणी। स्रोत: उपरोक्त URL

  • CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap” — 2026 वह साल होगा जब फोकस “कोड जनरेशन की स्पीड” से हटकर “कोड क्वालिटी और गवर्नेंस” पर आ जाएगा। साक्ष्य स्तर: द्वितीय। स्रोत: https://tfir.io/ai-code-quality-2026-guardrails

  • New Relic (2026). The 2026 State of AI Coding Report. 78% टीमों ने पाया कि AI कोड प्रोडक्शन में जाने के बाद ज़्यादा इंसीडेंट हो रहे हैं; 62% तकनीकी लीडर्स ने स्वीकार किया कि उनकी टीमें “बिना रिव्यू किए ही AI कोड भेज देती हैं”; 96% का मानना है कि ऑब्ज़र्वबिलिटी (observability) अनिवार्य है। साक्ष्य स्तर: प्रथम (विक्रेता रिपोर्ट)। स्रोत: https://newrelic.com/resources/report/2026-state-of-ai-coding

  • Microsoft 2026 वर्क ट्रेंड इंडेक्स वार्षिक रिपोर्ट (2026.5.5)। 20,000 AI कर्मियों पर सर्वेक्षण, 10 देशों में; 82% नेताओं की योजना अगले 12-18 महीनों में AI एजेंटों के साथ कार्यबल विस्तार की है; 81% को AI एजेंटों के मध्यम या बड़े पैमाने पर एकीकरण की उम्मीद है; 24% ने एंटरप्राइज़-स्तर पर तैनाती की है; 49% Copilot वार्तालाप संज्ञानात्मक कार्यों का समर्थन करते हैं; 58% AI उपयोगकर्ताओं ने “एक साल पहले असंभव काम” किए हैं, और Frontier Professionals में यह अनुपात 80% तक पहुँच गया है। साक्ष्य स्तर: प्रथम। स्रोत: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf

  • Microsoft FY26 पुनरावलोकन: AI प्रयोग से फ्रंटियर ट्रांसफॉर्मेशन तक (2026.7.28)। EY ने Microsoft 365 Copilot को 150,000 कर्मचारियों तक पहुँचाया, जिससे 25 लाख घंटे और लगभग 250 मिलियन डॉलर की बचत हुई; इसे 400,000 वैश्विक कर्मचारियों तक विस्तारित किया गया, 95% गति वृद्धि, 37% वित्तीय परिचालन लागत में कमी, और अधिकतम 90% मैन्युअल वर्कफ़्लो में कटौती हुई। Atos ने Copilot को 56 देशों में 56,000 कर्मचारियों और 19,000 AI एजेंट्स तक पहुँचाया, जिसमें एकीकृत पहचान, सुरक्षा, अनुपालन और गवर्नेंस कंट्रोल प्लेन शामिल है। साक्ष्य स्तर: प्रथम स्तर (Microsoft आधिकारिक पुनरावलोकन)। स्रोत: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Atos Group और Microsoft की रणनीतिक साझेदारी (2026.6.9)। Atos ने 56 देशों में 56,000 कर्मचारियों के लिए Microsoft 365 E7 (Frontier Suite) तैनात किया है, साथ ही 19,000 AI एजेंट भी शामिल किए हैं; Entra/Defender/Intune/Purview/Agent 365 के लिए एकीकृत नियंत्रण तल (control plane) बनाया गया है। साक्ष्य स्तर: प्रथम (दोनों कंपनियों की संयुक्त प्रेस विज्ञप्ति)। स्रोत: 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 (2025.9 में ओपन-सोर्स, 2026 H1 में विकास). 5-चरणीय गेटेड प्रक्रिया /speckit.constitution → /specify → /plan → /tasks → /implement, साथ में /clarify /analyze; मॉडल-अज्ञेयवादी (Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code — सभी कनेक्ट हो सकते हैं)। साक्ष्य स्तर: प्राथमिक। स्रोत: https://github.com/github/spec-kit

  • AWS Kiro (2025.7 में लॉन्च, 2026 H1 में विकास). तीन-चरणीय वर्कफ़्लो: आवश्यकता → डिज़ाइन → कार्य; spec पूर्व-परिभाषित एजेंट क्रियाओं को ट्रिगर करता है; spec लिखे बिना शुरू नहीं होता। साक्ष्य स्तर: प्राथमिक। स्रोत: https://kiro.dev/

  • OpenAI Codex + AGENTS.md + Skills (2025-2026). Codex 2026.6 में साप्ताहिक सक्रिय उपयोगकर्ता 5 मिलियन+ हैं, जिनमें 20% गैर-डेवलपर हैं; AGENTS.md + Skills संयोजनीय निर्देश सेट हैं। साक्ष्य स्तर: प्रथम (OpenAI आधिकारिक घोषणा)। स्रोत: https://developers.openai.com/codex/skills

  • Claude Code (Anthropic, 2026 H1). CLAUDE.md + .claude/rules/ + Skills प्रणाली; 2026.2 में Anthropic आधिकारिक मार्केटप्लेस में शामिल; Skills रिपॉजिटरी GitHub पर 11.2 लाख स्टार्स; 2026.2 G राउंड में 2.5 बिलियन डॉलर की वार्षिक आवर्ती आय का खुलासा। साक्ष्य स्तर: प्रथम। स्रोत: https://code.claude.com/docs/en/claude-directory

  • JetBrains AI Pulse Survey (2026.1). दुनिया भर के 10,000+ पेशेवर डेवलपर्स पर किया गया सर्वेक्षण, 8 भाषाओं में स्थानीयकृत; Claude Code CSAT 91% / NPS 54 (उद्योग में सर्वोच्च); कार्यस्थल पर Claude Code अपनाने की दर 18% (9 महीनों में 3% से 6 गुना बढ़ोतरी), उत्तरी अमेरिका में 24%; Copilot कार्यस्थल पर 29% अपनाया गया लेकिन विकास रुका हुआ; Cursor 18%. साक्ष्य स्तर: प्रथम श्रेणी। स्रोत: https://www.jetbrains.com/lp/tools/ai-tools/

  • Pragmatic Engineer Newsletter (2026.2). 15,000 डेवलपर्स का सर्वेक्षण; 46% ने Claude Code को “सबसे पसंदीदा” चुना, Cursor 19%, Copilot 9%। साक्ष्य स्तर: प्रथम श्रेणी। स्रोत: https://newsletter.pragmaticengineer.com/

  • Alibaba Qoder (अगस्त 2025 → जुलाई 2026)। अगस्त 2025 में Alibaba ने इसे लॉन्च किया; 15 मई 2026 को Qoder 1.0 को Autonomous Agent Development Workbench में अपग्रेड किया गया; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; 28 मई 2026 को Cloud Agents (मैनेज्ड एजेंट रनटाइम); 21 जुलाई 2026 को Qoder Security; मई 2026 में वैश्विक उपयोगकर्ता 5 मिलियन+; DingTalk CLI एकीकरण; 20 मई 2026 को Tongyi Lingma का नाम बदलकर Qoder CN कर दिया गया। साक्ष्य स्तर: प्राथमिक। स्रोत: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525

  • vibecoding.app / thebcms.com / tfir.io (2026 H1)। Spec Kit पाँच-चरणीय कमांड, SDD टूल मूल्यांकन तुलना, EARS एनोटेशन विधि। साक्ष्य स्तर: द्वितीयक (तृतीय-पक्ष मूल्यांकन)। स्रोत: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development

  • EU AI Act / Code of Practice (2026.8.2 तक पूर्ण कार्यान्वयन)। उच्च-जोखिम AI सिस्टम के लिए अनुपालन की अंतिम तिथि 2026.8.2 है; मौजूदा GPAI मॉडल को 2027.8.2 तक का विस्तार मिला है; अधिकतम जुर्माना €35 मिलियन या वैश्विक राजस्व का 7% है; Art. 9-15 में जोखिम प्रबंधन, डेटा गवर्नेंस, दस्तावेज़ पारदर्शिता, मानवीय निगरानी, सटीकता और मजबूती शामिल हैं। साक्ष्य स्तर: प्रथम (विनियम + द्वितीयक अनुपालन विश्लेषण)। स्रोत: 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)। 44% समस्याओं का मूल कारण संदर्भ (context) की कमी है। साक्ष्य स्तर: द्वितीय (विक्रेता रिपोर्ट)। स्रोत: https://www.qodo.ai/reports/state-of-ai-code-quality/

धीरे-धीरे AI सीखें: IAIUSE शोध-आधारित सलाहकार ब्लॉग

दूरसंचार उद्योग में AI अनुप्रयोग

भारतीय दूरसंचार उद्योग तेज़ डिजिटल परिवर्तन से गुज़र रहा है, और AI इस प्रक्रिया को आगे बढ़ाने वाला प्रमुख चालक बन गया है। Reliance Jio का AI-संचालित नेटवर्क ऑप्टिमाइज़ेशन प्लेटफ़ॉर्म इसका उदाहरण है, जो AI का उपयोग करके नेटवर्क प्रदर्शन को बेहतर बनाता है और ग्राहक अनुभव में सुधार करता है। TCS (Tata Consultancy Services) भी AI का उपयोग करके टेलीकॉम ऑपरेटरों के लिए प्रेडिक्टिव मेंटेनेंस और ग्राहक सेवा स्वचालन समाधान प्रदान करता है।

वित्तीय उद्योग में AI अनुप्रयोग

भारतीय वित्तीय क्षेत्र भी दक्षता बढ़ाने और जोखिम कम करने के लिए AI तकनीक को सक्रिय रूप से अपना रहा है। HDFC Bank का AI-संचालित क्रेडिट स्कोरिंग और धोखाधड़ी का पता लगाने वाला सिस्टम ग्राहक व्यवहार का विश्लेषण करता है और वैयक्तिकृत सेवाएँ प्रदान करता है। SBI (State Bank of India) AI का उपयोग करके अपने 200+ वर्षों के पुराने लेन-देन रिकॉर्ड का विश्लेषण करता है और डिजिटल ऋण प्रसंस्करण को स्वचालित करता है। ICICI Bank का AI चैटबॉट iPal भी ग्राहक सेवा में AI के उपयोग का एक उल्लेखनीय उदाहरण है।

विनिर्माण उद्योग में AI अनुप्रयोग

भारतीय विनिर्माण क्षेत्र भी उत्पादकता और गुणवत्ता सुधारने के लिए AI का उपयोग कर रहा है। Infosys का AI-संचालित प्रेडिक्टिव मेंटेनेंस प्लेटफ़ॉर्म उत्पादन डेटा का विश्लेषण करता है और उपकरण विफलता की भविष्यवाणी करता है। Wipro की AI समाधान ऑटोमोटिव और फार्मास्युटिकल क्षेत्रों में क्वालिटी कंट्रोल और आपूर्ति श्रृंखला अनुकूलन के लिए तैनात किए जा रहे हैं।

ई-कॉमर्स उद्योग में AI अनुप्रयोग

भारतीय ई-कॉमर्स क्षेत्र भी ग्राहक अनुभव और बिक्री बढ़ाने के लिए AI का उपयोग कर रहा है। Flipkart का AI-संचालित अनुशंसा इंजन ग्राहक व्यवहार का विश्लेषण करता है और वैयक्तिकृत उत्पाद सुझाव देता है। Myntra का AI-आधारित फैशन स्टाइलिस्ट उपयोगकर्ता की प्राथमिकताओं को समझकर स्टाइल सुझाव प्रदान करता है। Amazon India भी AI का उपयोग करके वेयरहाउस ऑपरेशंस को अनुकूलित करता है और डिलीवरी लॉजिस्टिक्स में सुधार करता है।

नियामक आवश्यकताएँ

दूरसंचार, वित्त, विनिर्माण और ई-कॉमर्स सभी उद्योग नियामक चुनौतियों का सामना करते हैं। भारत में DPDP Act 2023 + DPDP Rules 2025 (व्यक्तिगत डेटा संरक्षण) और CERT-In Directions 2022 (साइबर सुरक्षा इन्सिडेंट रिपोर्टिंग के लिए 6-घंटे की समय-सीमा) इन उद्योगों को सख्त सुरक्षा और गोपनीयता मानकों का पालन करने की आवश्यकता है। RBI की साइबर सुरक्षा फ्रेमवर्क, MeitY के IT Rules 2021, और NCIIPC के महत्वपूर्ण सूचना अवसंरचना दिशानिर्देश भी लागू होते हैं।

केस स्टडीज़

  • दूरसंचार: Reliance Jio का AI-संचालित नेटवर्क ऑप्टिमाइज़ेशन प्लेटफ़ॉर्म नेटवर्क प्रदर्शन को बेहतर बनाने और ग्राहक अनुभव सुधारने के लिए AI का उपयोग करता है।
  • वित्त: HDFC Bank का AI-संचालित धोखाधड़ी का पता लगाने वाला सिस्टम ग्राहक व्यवहार का विश्लेषण करता है और वैयक्तिकृत सेवाएँ प्रदान करता है। SBI का AI डिजिटल ऋण प्रसंस्करण को स्वचालित करता है।
  • विनिर्माण: Infosys का प्रेडिक्टिव मेंटेनेंस प्लेटफ़ॉर्म उत्पादन डेटा का विश्लेषण करता है और उपकरण विफलता की भविष्यवाणी करता है।
  • ई-कॉमर्स: Flipkart का अनुशंसा इंजन ग्राहक व्यवहार का विश्लेषण करता है और वैयक्तिकृत उत्पाद सुझाव देता है।

निष्कर्ष

AI तकनीक भारत के दूरसंचार, वित्त, विनिर्माण और ई-कॉमर्स उद्योगों में तेज़ी से महत्वपूर्ण भूमिका निभा रही है। ये उद्योग DPDP Act 2023, CERT-In Directions 2022, RBI फ्रेमवर्क, और MeitY दिशानिर्देशों जैसे सख्त नियामक आवश्यकताओं और सुरक्षा मानकों का पालन करते हैं। AI तकनीक को अपनाकर, TCS, Infosys, Wipro, HDFC, SBI, ICICI, Flipkart, और Myntra जैसी भारतीय कंपनियाँ दक्षता बढ़ा रही हैं, जोखिम कम कर रही हैं, और बेहतर ग्राहक अनुभव प्रदान कर रही हैं।

]]> AI कोड समस्या दर 1.7×, सुरक्षा कमज़ोरियाँ 2.74×—AI आपके नियम नहीं देखता। Spec Kit, Kiro, Codex, Claude Code, Qoder 2026 H1 में नियम-संचालित हो रहे हैं। 【Regelgedreven】Spec-Driven Development: de hoogste ROI in AI-tijdperk — de transformatie van software-engineering in het AI-tijdperk — Langzaam AI leren 177 https://iaiuse.com/nl/posts/spec-gedreven-ontwikkeling-ai-tijdperk-hoogste-roi-engineering-actie 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z

Databronnen in dit artikel: CodeRabbit 2025.12 / New Relic 2026-rapport, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms-aankondiging, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. De cases zijn representatieve scenario’s en verwijzen niet naar specifieke bedrijven.

Je grootste fout is niet dat je geen tools hebt gekocht, maar dat je geen CLAUDE.md hebt geschreven

De CIO van een regionale bank klaagde bij me: de AI-tools zijn aangeschaft, de modellen zijn geïmplementeerd, het personeel is getraind — en toch bleef de deliverytijd in de eerste helft van 2026 vrijwel onveranderd. De leider van het kernteamsysteem was nog directer: “De code die AI schrijft is bruikbaar, maar we moeten hem elke keer helemaal herschrijven — het begrijpt onze bankregels niet, begrijpt de compliance-eisen niet, en weet niet hoe het moet integreren met dat 30 jaar oude legacy-systeem.”

Het probleem is niet dat AI niet sterk genoeg is — het probleem is dat jullie de regels niet hebben vastgelegd. CodeRabbit publiceerde in december 2025 een analyse van 470 open-source PR’s met cijfers die breed werden geciteerd: AI-ondersteunde PR’s bevatten gemiddeld 10,83 problemen, puur handmatige PR’s 6,45 — 1,7 keer zoveel, 70% meer bugs dan handmatig werk. In 2026 is het verhaal niet omgedraaid: New Relic constateerde in de 2026 State of AI Coding Report dat 78% van de teams meer incidenten rapporteerde na het uitrollen van AI-code, en 62% van de technisch leiders gaf toe dat hun teams “vol vertrouwen AI-code vrijgeven zonder regel-voor-regel review” (New Relic officieel rapport 2026, score 0,866, primaire bron). Beide datasets vertellen hetzelfde verhaal — AI mist geen capaciteit, het mist context.

Vanuit het perspectief van augustus 2026 moet elk verhaal over “versnelde AI-transformatie” worden bekeken tegen de volgende achtergrond:

| Kamp | Vooruitgang (2026 H1) | Tegenvoorbeeld (2026 H1) |
|—|—|—|—|
| EY | Microsoft 365 Copilot uitgerold naar 150.000 medewerkers, bespaart 2,5 miljoen uur / $250 miljoen; uitbreiding naar 400.000 medewerkers wereldwijd | Geeft tegelijkertijd toe dat de 95% versnelling en 37% kostenverlaging in financiële operaties alleen gelden onder de voorwaarde van “eerst standaardiseren” |
| Atos | Uitgerold naar 54 landen / 56.000 medewerkers; draait tegelijkertijd 19.000 AI-agents met een uniform controle-vlak voor identiteit/beveiliging/compliance/governance | Houdt strikt vast aan “eerst de governance-capaciteiten van Agent 365 live, dan pas opschalen” |
| Microsoft zelf | 2026 Work Trend Index: 82% van de leiders is van plan om binnen 12-18 maanden AI-agents in te zetten om de workforce uit te breiden | Erkent in dezelfde periode dat “de organisatorische verandering achterloopt op individueel gebruik” — dit is de kernparadox binnen het Frontier Firm-concept |

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

Deze twee vergelijkingen maken één ding duidelijk: zonder governance is opschalen gewoon risico vermenigvuldigen met N. De “snelheid” van EY/Atos/Microsoft gaat niet om de snelheid van het model, maar om het feit dat “de organisatie eerst de vraag beantwoordt hoe AI ingezet moet worden”. Dit is de achtergrond waartegen Spec-Driven Development (SDD) in H1 2026 echt mainstream werd — niet omdat engineers een voorkeur hebben voor documentatie, maar omdat je zonder specs simpelweg niet kunt overleven in een omgeving met 19.000 agents.

Dit artikel behandelt drie zaken: 1) waarom defecten in AI-code tot meer dan 1,7 keer ernstiger zijn dan handgeschreven code; 2) hoe GitHub, AWS, OpenAI, Anthropic en Alibaba in H1 2026 naar hetzelfde paradigma toe bewegen — AI-gedrag sturen via documentatie; 3) waarom spec-driven development een organisatorische capaciteit is, geen toolkeuze, en wat de drie implementatiefasen in H1 2026 zijn.

AI-code vs menselijke code: defectverdeling (analyse van 470 open-source PR's) CodeRabbit 2025.12 rapport｜alle cijfers zijn veelvouden van AI / menselijk (basislijn 1.0)

Staflengte = AI-defecten als veelvoud van menselijk; basislijn 1.0× = menselijk niveau

Basis 1.0×

Totaal aantal problemen

1.7×
AI 10.83 vs menselijk 6.45 / PR

Logica / correctheidsfouten

1.75×

Codekwaliteit / onderhoudbaarheid

1.64×

Beveiligingsbevindingen (gecombineerd)

1.57×

Onjuiste wachtwoordverwerking

1.88×

XSS-kwetsbaarheden

2.74×
↑ Hoogste

AI-code zonder normatieve beperkingen scoort op elke dimensie hoger dan menselijk
Financieel/telecom = compliance-afstemming, wachtwoordbeheer, versleuteling van gevoelige velden; AI ziet dit allemaal niet

I. AI-defectpercentage is geen modelprobleem, maar een contextprobleem

In het CodeRabbit-rapport wordt één zin steeds opnieuw geciteerd: “AI mist lokale bedrijfslogica: modellen voorspellen codepatronen op basis van statistiek, niet op basis van semantisch begrip. Zonder strikte beperkingen missen ze de systeemregels die senior engineers hebben geïnternaliseerd.”

Deze zin verklaart waarom CodeRabbit’s eigen AI-programmeerplatform (een bedrijf dat zich specifiek richt op AI-codebeoordeling) deze cijfers eerder zag dan anderen — ze bekijken dagelijks duizenden pull requests en zien dagelijks hoe AI-geschreven code eruitziet. De “belangrijkste” bevinding is niet het totaal, maar de verdeling:

  • Logica/correctheid +75%: bedrijfslogicafouten, afhankelijkheidsfouten, control flow-fouten, configuratiefouten — dit soort problemen komt niet altijd naar boven in tests, maar veroorzaakt wel incidenten in de productieomgeving.
  • Codekwaliteit +64%: inconsistente naamgeving, onduidelijke structuur, afwijking van projectpatronen — dit is de “categorie met de grootste verschillen”. Senior engineers zien in één oogopslag: “dit is niet hoe wij hier schrijven”.
  • Beveiliging +57% (XSS-klasse het hoogst met 2,74×): onjuiste wachtwoordverwerking (1,88×), onveilige objectreferenties (1,91×), lekken van gevoelige informatie, onveilige deserialisatie (1,82×) — in de financiële sector is dit niet de vraag “kan het werken”, maar “mag het wel uit”.

Het probleem is niet dat AI niet sterk genoeg is. Het probleem is dat het niets ziet.

Terug naar het echte knelpunt van die CIO: drie concrete faalpunten van AI in financiële kernsystemen.

Ten eerste: AI ziet de 30 jaar oude reconciliatielogica niet. De risicoregels van een bank staan in stored procedures van het kernssysteem — 30 jaar geleden geschreven, niemand kent ze nog volledig. De door AI gegenereerde code ziet er logisch correct uit, maar in de productieomgeving activeert ze die reconciliatiecheck die niemand zich herinnert, en de hele batch transacties faalt.

Ten tweede: AI ziet de compliance-eisen niet. Wachtwoorden moeten via het keymanagementsysteem, gevoelige velden moeten versleuteld worden opgeslagen, logs mogen geen klantinformatie bevatten — dit zijn harde toezichtseisen, vastgelegd in interne richtlijnen. AI weet dit niet, schrijft code die draait maar de compliance-review niet doorstaat.

Ten derde: AI ziet je technische schuld niet. Dat 30 jaar oude hostsysteem gebruikt een eigen interfaceprotocol, de documentatie is allang verdwenen. AI schrijft code volgens de gangbare RESTful-standaard, en bij de livegang blijkt de interface niet te matchen — twee weken herbewerking.

Terug naar die andere cijfers van New Relic: 62% van de teams “stuurt vol vertrouwen AI-code live zonder review”, 78% rapporteert meer incidenten na de livegang. Die twee cijfers samen zeggen eigenlijk: het defectpercentage van AI-code is op zichzelf niet het probleem — “ik weet niet welke defecten de AI-code heeft” is het probleem.

Typisch scenario: een regionale bank introduceert AI-ondersteunde ontwikkeling van de risicobeheermodule van haar kernsystemen. Binnen drie maanden stijgt het aantal afgewezen zaken bij de compliance-review aanzienlijk. De belangrijkste problemen zijn interne regels rond wachtwoordbeheer, encryptie van gevoelige velden en logcompliance. Deze regels staan allemaal in interne documenten, maar de AI ziet ze niet. Toen het team later de kernregels in een CLAUDE.md-bestand zette, daalde het aantal afwijzingen aanzienlijk.

Twee: De vijf platforms in H1 2026 — verschillende wegen, dezelfde “regelgedreven” bestemming

In juli 2025 lanceerde GitHub Spec Kit; begin 2026 volgden AWS Kiro, OpenAI Codex en Anthropic Claude Code; in mei 2026 nam Alibaba Qoder “Spec-Driven Workflow” op in haar productpositionering. In H1 2026 kwamen de vijf platforms bij hetzelfde paradigma uit: documentatie als leidraad voor AI-gedrag. Dit is geen uitvinding van één bedrijf, maar de collectieve reactie van de sector op de “AI-codekwaliteitscrisis”.

Normgedreven paden van vijf platforms (2025-2026 H1) GitHub Spec Kit Open source 2025.9 constitution.md Vijf fasen gating: constitution → specify → plan → tasks → implement Model-onafhankelijk, 8+ agents Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md Drie fasen workflow: Vraag → Ontwerp → Taken Spec-driven in IDE-workflow Hooks triggeren automatische agents Compliance/audit-hooks ingebouwd Zonder spec geen start OpenAI Codex 2025-2026 AGENTS.md + Skills-systeem Compositie-instructieset Teamgedeelde configuratie 5M+ wekelijks actief (2026.6) 20% niet-ontwikkelaars Van coderen naar universele agent Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + Vaardigheden (Officiële markt 2026.2) + MCP-ecosysteem CSAT 91% / NPS 54 $2.5B ARR（2026.2） GitHub 112k sterren Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Quest-modus autonome uitvoering + Expert-modus team + RepoWiki-context 5M+ wereldwijde gebruikers (2026.5) 2026.7.21 Qoder Security DingTalk CLI geïntegreerd Gemeenschappelijk paradigma: schrijf "hoe we met AI samenwerken" expliciet als document, in de repository Laat alle mensen en alle AI-agenten tegen dezelfde norm werken — dat is de essentie van normgedreven

Laten we per platform kijken naar de nieuwste ontwikkelingen in H1 2026:

GitHub Spec Kit: referentie-implementatie, vijf fasen met poortcontroles. In september 2025 open-sourced, tegen de eerste helft van 2026 uitgegroeid tot de referentie-implementatie in de industrie. 5 kerncommando’s + 2 aanvullingen: /speckit.constitution (niet-onderhandelbare principes), /speckit.specify (wat en waarom), /speckit.plan (hoe aan te pakken), /speckit.tasks (taken opsplitsen), /speckit.implement (uitvoeren), plus /clarify en /analyze. Het belangrijkste ontwerpkenmerk is modelonafhankelijkheid — dezelfde spec/plan/tasks-bestanden zijn niet gebonden aan een specifieke uitvoeringsagent; Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf en Qwen Code kunnen ze allemaal gebruiken. Daardoor is het uitgegroeid tot een “organisatiebreed SDD-protocol” in plaats van een GitHub-specifiek product (vibecoding.app review juni 2026, score 0,816, secundaire bron).

AWS Kiro: van normgedreven denken naar de IDE. Gelanceerd in juli 2025, en in de eerste helft van 2026 doorgegroeid tot een volwaardige Agent IDE. Een workflow in drie fasen: requirements → ontwerp → taken. Het verschil met Spec Kit zit ‘m in de ‘hooks’ — bij Kiro kunnen spec-bestanden vooraf gedefinieerde agent-acties triggeren, waardoor stappen zoals compliance, audits of deployment — die normaal een extern systeem vereisen — direct in de workflow worden ingebed. Kies voor Kiro als je je team wilt dwingen om specificaties te schrijven — want zonder spec-bestand start Kiro simpelweg niet (AWS Kiro officieel, juli 2025; Kiro.dev-documentatie, 2026).

OpenAI Codex: AGENTS.md + composable Skills. In 2025-2026, AGENTS.md moved to the center of the ecosystem. Skills are the key extension of H1 2026: they pre-assemble workflows like “reading Excel sheets,” “generating SQL,” or “running data migrations,” so you can call them like Lego blocks. By June 2026, Codex had surpassed 5 million weekly active users, 20% of whom are non-developers — an overlooked signal: spec-driven work is no longer just for engineering teams; it’s for everyone. Product, operations, and risk teams are all writing AGENTS.md (OpenAI announcement, June 2, 2026; thebcms.com review, 2026, score 0.801).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic noemt het projectinstructiedocument CLAUDE.md (februari 2026 naar de officiële markt), .claude/rules/ (regels op basis van directoryhiërarchie), Skills (deelbare workflows). Claude Code is het best beoordeelde hulpmiddel onder ontwikkelaars in H1 2026 — JetBrains 2026.1-onderzoek geeft een CSAT van 91% en een NPS van 54, twee onafhankelijke onderzoeken (Pragmatic Engineer 2026.2) bevestigen dit. Dit is de hoogste score in de huidige AI-programmeertools-sector (uvik.net 2026.5, 0.956 score, samenvatting van primaire bronnen). Claude Code groeide in 9 maanden van 0 naar 2,5 miljard dollar aan geannualiseerde omzet (2026.2 Anthropic G-ronde), 112.000 stars op GitHub (Skills-repository) — ontwikkelaars stemmen met hun voeten en tonen de echte waarde van op regels gebaseerde aanpak.

Alibaba Qoder: regelgedreven in de Chinese markt. Uitgebracht in augustus 2025, geüpgraded naar versie 1.0 op 15 mei 2026, en daarmee officieel getransformeerd van een “AI IDE” naar een “Autonomous Agent Development Workbench”. De Spec-Driven Workflow werd gelanceerd samen met Quest Mode (autonome multi-bestandstaken), Expert Mode (parallelle expertteams) en RepoWiki (repository-kennisdomein). Op 28 mei 2026 kwamen Cloud Agents (volledig beheerde agent-runtime) beschikbaar, gevolgd door Qoder Security (nalevings- en beveiligingsmogelijkheden) op 21 juli, en in dezelfde maand verscheen de mobiele versie (Android/iOS/HarmonyOS). In mei 2026 passeerde het wereldwijde gebruikersaantal de 5 miljoen, en DingTalk CLI vermeldt het als een van de ondersteunde agent-uitvoeringsomgevingen (Yahoo Finance 2025; Alibaba Cloud official 2026; Baidu Baike 2026.7).

Gemeenschappelijk paradigma: leg expliciet vast hoe wij met AI samenwerken in een document, plaats dat in de repository, en laat alle mensen én alle AI-agenten tegen dezelfde set afspraken werken. De vijf platforms verschillen in implementatiedetails (bestandsnamen/aantal fasen/hook-mechanismen), maar het doel is exact hetzelfde.

Waarom gebeurt dit nu allemaal in H1 2026? Omdat de AI-capaciteitsdrempel inmiddels is overschreden — Claude Code als autonome agent, Codex met parallelle multi-agenten, Cursor met multi-file refactoring: AI is geen “autocomplete-tool” meer, maar een “collega”. En de onboarding-documentatie die je een nieuwe collega geeft, moet ook leesbaar zijn voor AI.

3. Normgedreven werken is een organisatorische capaciteit, geen toolkeuze

Dit is het belangrijkste punt voor beslissers. Normgedreven werken is geen kwestie van tools kiezen, maar van definiëren hoe onze organisatie met AI samenwerkt. Of je nu kiest voor GitHub Spec Kit of Claude Code maakt niet uit — wat telt is of je de normen hebt vastgelegd in een document, in de repository hebt geplaatst, en of iedereen én alle AI-systemen daarnaar werken.

Zonder die basis zorgen zelfs de beste tools er alleen maar voor dat je team sneller meer technische schuld creëert.

Als we dit in het perspectief plaatsen van grootschalige uitrol in de eerste helft van 2026, wordt het bewijs nog sterker. In de FY26-retrospective van juli 2026 beschrijft Microsoft de cases van EY en Atos als het ‘Frontier Firm’-sjabloon — niet omdat de modellen nieuw zijn, maar omdat beide bedrijven eerst de vraag ‘hoe zetten we AI in?’ hebben beantwoord:

EY: eerst governance, dan schaalbaar resultaat. EY rolde Microsoft 365 Copilot in 2024-2025 uit naar 150.000 medewerkers, met 2,5 miljoen bespaarde uren en circa 250 miljoen dollar aan besparingen als resultaat. De voorwaarde was dat het AI-governancekader eerst stond: EY bouwde met Power Platform, Copilot Studio, Azure, Foundry en Fabric één uniforme toolchain, waarin compliance, governance en audit in hetzelfde fundament werden ondergebracht. Pas daarna kwamen de 95% versnelling, 37% lagere financiële operationele kosten en tot 90% minder handmatige workflows. De vicepresident van EY zei het tijdens de AI Tour van 2026 heel direct: “Wij rollen niet eerst AI uit en repareren daarna de governance; wij bouwen eerst de governance en rollen daarna AI uit.”

Atos: één controle-vlak voor 19.000 agents. Atos is één van de eerste organisaties wereldwijd die Microsoft 365 E7 (Frontier Suite) heeft uitgerold, met Copilot voor 56.000 medewerkers in 54 landen. Tegelijkertijd draaien er 19.000 AI-agents – van interne IT en business units tot klantprojecten, allemaal gebouwd met Foundry + Copilot Studio. De sleutel tot dit succes is “één controle-vlak”: Entra (identiteit) + Defender (beveiliging) + Intune (apparaten) + Purview (compliance) + Agent 365 (agent-governance), vijf componenten die aan elkaar zijn gekoppeld. Deze koppeling vertaalt zich in de financiële sector naar “等保 (classificatie en beveiligingstesten) + data-exportbeoordeling + algoritme-registratie + audit + model-governance” – het is een governance-architectuur, geen op zichzelf staande AI-tool.

Microsofts eigen ‘organisatieveranderingsparadox’. In het Work Trend Index-rapport van 2026 geeft Microsoft zelf toe: “het tempo van organisatorische verandering blijft achter bij individueel gebruik.” Van de 20.000 AI-gebruikers die zij ondervroegen, zegt 82% van de leiders te plannen om binnen 12-18 maanden hun personeelsbestand uit te breiden met AI-agenten, maar slechts 24% heeft dit inmiddels op bedrijfsniveau uitgerold. 81% van de leiders verwacht dat AI-agenten in matige tot hoge mate worden geïntegreerd in hun AI-strategie — maar ook hier geldt: slechts 24% heeft dit daadwerkelijk gerealiseerd. Dit betekent dat de meeste organisaties nog 12-18 maanden verwijderd zijn van de kloof tussen ‘voorbereiden’ en ‘daadwerkelijk doen’. Hoe die kloof wordt overbrugd, is vooral een kwestie van normgedreven aanpak.

Bron: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, primaire PDF-bron); Futurum Group 2026.1.26-analyse (secundaire bron).

Inzicht één: investeren in normen levert een hoog rendement op.

CodeRabbit’s data biedt een duidelijke basis voor ROI-berekening: de AI-codeprobleemratio ligt op ongeveer 1,7x en beveiligingskwetsbaarheden nemen met 2,74x af. Dat betekent:

  • Minder herbewerking (in de financiële sector kost één compliance-review al snel 2-4 weken)
  • Minder beveiligingsincidenten (de boetes en reputatieschade van één datalek)
  • Lagere onderhoudskosten (een technische schuldreductie van 40% is een gangbaar cijfer)

Het schrijven van een CLAUDE.md/AGENTS.md-projectstandaard is de engineering-actie met het hoogste ROI in het AI-tijdperk. De EY-case geeft een realistische vertaalslag: 150.000 medewerkers met Copilot, een besparing van 250 miljoen dollar. Let op: EY bespaarde niet omdat “het tool zo goed was”, maar omdat “de standaard de waarde van het tool daadwerkelijk verzilverde”.

Inzicht twee: veranker de standaard in organisatieprocessen, niet in individuen.

Als een standaard alleen in het hoofd van één senior engineer bestaat, is hij verdwenen zodra die persoon vertrekt. Hij moet worden vastgelegd in:

  • Repository-documentatie (AGENTS.md / CLAUDE.md / constitution.md)
  • CI-gates (automatische controle op naleving van de standaard)
  • Gedeelde teamconfiguratie (het Skills-systeem maakt de standaard beschikbaar voor het hele team)

Laat normen een organisatorisch bezit worden, geen persoonlijke vaardigheid. Dit is vooral belangrijk in de financiële sector — jullie compliance-eisen, beveiligingsregels en bedrijfsregels zijn bezittingen van de organisatie, niet het “ervaringskapitaal” van één engineer. De 19.000 agents van Atos draaien in 54 landen, niet omdat “iemand het snapt”, maar omdat “het systeem het afdwingt”.

Inzicht drie: gating is belangrijker dan snelheid.

De vijf fasen van gating in GitHub Spec Kit (constitution → specify → plan → tasks → implement), Claude Code’s “geen code schrijven voordat tests falen”, en Kiro’s “geen spec, geen start” doen allemaal hetzelfde: een “rem” zetten tussen AI en het uiteindelijke resultaat. Elke stap levert een controleerbaar artefact op (spec.md, plan.md, tasks.md), en elke stap kan vóór het genereren van code worden afgekeurd of aangepast.

Hoe autonomer de AI, hoe meer gating nodig is. De Change Advisory Board (Change Advisory Board (CAB)) in de financiële sector, algoritme-registratieprocedures en de classificatie- en beveiligingsaudit (ISO 27001 + NCSC 指引, een Chinees verplicht beveiligingsbeoordelingssysteem voor informatiesystemen) zijn in wezen allemaal vormen van gating vóór productie. AI-code heeft vergelijkbare gating nodig, alleen in een andere vorm. De 62% teams in het New Relic-rapport van 2026 die “vol vertrouwen zonder review deployen”, betalen voor dat vertrouwen met een hoger incidentcijfer (78%).

Drie fasen voor normimplementatie in de financiële sector (2026 H1 praktijkversie) Fase 1: Regels inventariseren 2-4 weken | Meest tijdrovend, hoogste ROI Compliancy-eisenlijst (gegevensbescherming/uitgaand/registratie) Beveiligingsregels (wachtwoord/encryptie/logs) Bedrijfsregels (risicobeheer/transacties/billing) Technische beperkingen (oude API's/versiebeperkingen) Leveranciersbeheer (contracten/audits/aansprakelijkheid) Verspreide regels verzamelen Structureren in documentatie Fase 2: in de repository 1-2 weken | in repo, AI laadt automatisch CLAUDE.md / AGENTS.md constitution.md Skills-definitie (deelbare workflows) Gate-procesontwerp (vijf fasen) .claude/rules/ (gelaagde regels) Regels in repository plaatsen, AI laadt automatisch Fase 3: institutionalisering Continu | van tool naar organisatiecapaciteit CI-gate (automatische review) Teamgedeelde configuratie (Skills) Periodiek updatemechanisme (kwartaalreview) Metrieken (defectpercentage/nalevingsslagingspercentage) Agent-governance (Agent 365 niveau 1) Normen worden organisatie-activa, niet afhankelijk van individuen

Fase één kost de meeste tijd, maar heeft de hoogste ROI
Bij de meeste financiële organisaties liggen regels verspreid over documenten/e-mails/hoofden; de eerste ordening kost 3-8 weken

Vier. De drie echte implementatiefasen van H1 2026

Aan de hand van de financiële sector als voorbeeld: een pad in drie fasen, waar ook andere sterk gereguleerde sectoren hun voordeel mee kunnen doen. De praktijk bij EY en Atos in H1 2026 sluit precies op deze drie fasen aan.

Fase één: regels inventariseren (2-4 weken).

Dit is de fase die het meeste tijd kost, maar ook het hoogste rendement oplevert. Breng alle regels die verspreid over de organisatie bestaan in kaart:

  • Compliance-eisen: het absolute minimum voor financiële instellingen = Niveau 3 van de Chinese classificatie van cyberbeveiliging (等保, vergelijkbaar met NIS2) + beoordeling van grensoverschrijdende dataoverdracht (vergelijkbaar met een GDPR-transfer impact assessment) + algoritmeregistratie (vergelijkbaar met de EU AI Act) — als één onderdeel ontbreekt, kun je AI beter niet uitrollen. Daarbovenop komen nog rapportageverplichtingen aan toezichthouders, bescherming van klantgegevens, beperkingen op grensoverschrijdende datastromen, en de vraag welke data AI überhaupt mag zien.
  • Beveiligingsregels: wachtwoordbeheer, encryptiestandaarden, verwerking van gevoelige velden, loggingvereisten.
  • Bedrijfsregels: risicodrempels, claimvoorwaarden, transactielimieten, facturatie-logica.
  • Technische beperkingen: interfaces van legacy-systemen, databasenaming, versiebeperkingen van frameworks.
  • Leveranciersbeheer: hoe je in contracten eist dat leveranciers onze standaarden hanteren, en hoe je het AI-gebruik van leveranciers auditeert.

Typisch scenario: tijdens de inventarisatiefase ontdekt een effectenbedrijf dat de regels verspreid liggen over talloze Word-documenten, JIRA-wiki’s, persoonlijke e-mails en Excel-sheets — pas na het opruimen ontstaat een gestructureerde regellijst. Atos pakt het systematischer aan: zij splitsen de regels direct op in vijf categorieën — compliance, security, bedrijfsvoering, techniek en leveranciers — elk met een eigen governance-workflow, allemaal aangesloten op het control plane van Agent 365.

Dit is geen technische klus, maar een organisatorische: je moet compliance, security en de business bij elkaar brengen en de regels vastleggen waar iedereen achter staat. De eerste keer kost dit financiële organisaties doorgaans 3 tot 8 weken — maar het is een blijvend organisatorisch bezit.

Fase 2: vastleggen in de repository (1–2 weken).

Schrijf de regels uit fase 1 uit als documentatie en plaats ze in de repository. GitHub Spec Kit gebruikt constitution.md, Claude Code gebruikt CLAUDE.md, OpenAI Codex gebruikt AGENTS.md, en Alibaba Qoder gebruikt Spec Workflow. De bestandsnamen verschillen, maar het doel is hetzelfde: AI moet de regels laden zodra de repository wordt geopend.

Voorgestelde structuur (mainstream in H1 2026):

  • Projectoverzicht: Wat doet dit systeem en voor wie?
  • Niet-onderhandelbare principes: Veiligheids-, compliance- en bedrijfsmatige rode lijnen.
  • Technische stack en beperkingen: Welk framework, welke database, welke interface-standaarden.
  • Codeerstandaarden: Naamgevingsconventies, directorystructuur, minimale testdekking (geen verplicht TDD-ritme — specificeer gewoon de testdekking, de verplichte testpaden en de verboden paden; TDD is een optionele organisatorische keuze, geen harde eis vanuit de standaard).
  • Bedrijfsregels: Risicobeheerlogica, transactieregels, facturatieregels.
  • Compliance-eisen: Graded protection (等保, classificatie en beveiliging van informatie), grensoverschrijdende data-overdracht, toezichtsrapportage, en of AI-gegenereerde algoritmen geregistreerd moeten worden.
  • AI-gebruiksrichtlijnen: In welke scenario’s mag AI worden gebruikt, waar is menselijke beoordeling verplicht, en wat zijn de regels voor grensoverschrijdende data?
  • Leveranciersbeheer: Contractvoorwaarden, auditmechanismen, verantwoordelijkheidsverdeling.

Bijlage: CLAUDE.md-skelet voor de financiële sector (ca. 200 regels, direct te forken en aan te passen)

Hieronder staat een CLAUDE.md-skelet voor de modernisering van de kernsystemen van een joint-stock bank, georganiseerd volgens de volgorde “niet-onderhandelbare principes → compliance-eisen → AI-gebruiksrichtlijnen → bedrijfsregels → technische beperkingen”. Je hoeft niet vanaf nul te beginnen — vul gewoon de lege plekken in met de specifieke regels van jouw organisatie.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
# CLAUDE.md — <systeemnaam> AI-samenwerkingsrichtlijnen

> Toepassingsgebied: <systeemnaam> v<versie>, alle AI-agents (Claude Code / Cursor / Copilot / Codex)
> die in deze repository werken, dienen deze richtlijnen na te leven. Dit document wordt
> beheerd door de <governancecommissie>, met kwartaalreviews.
> Laatst bijgewerkt: <YYYY-MM-DD>

## 1. Projectoverzicht
- **Bedrijfspositionering**: naam kernsysteem / doelgroep / belangrijkste transactietypes
- **Kritieke keten**: transactie → risicobeheer → clearing → reconciliatie → rapportage
- **Niet-beschikbaar venster**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (geen wijzigingen toegestaan)
- **Kernafhankelijkheden**: upstream <systeem>, downstream <systeem>, platform voor regelgevende rapportage

## 2. Ononderhandelbare principes (rode lijnen — overtreding = merge geweigerd)

### 2.1 Beveiligings-rode lijnen
- Wachtwoorden, sleutels en tokens moeten verplicht via KMS (Key Management Service), **hardcoding verboden**, **printen in logs verboden**
- Gevoelige klantvelden (identiteitsbewijsnummer / kaartnummer / CVV / mobiel nummer) **moeten versleuteld worden opgeslagen**, platte tekst in database is verboden
- In logs is het volgende verboden: volledig identiteitsbewijsnummer, volledig kaartnummer, wachtwoord in platte tekst, combinatie klantnaam + mobiel nummer
- Externe API-aanroepen moeten verplicht via de API-gateway; directe verbindingen zijn verboden

### 2.2 Compliance-rode lijnen
- Door AI gegenereerde code die toegang heeft tot klantdata moet in de PR-beschrijving worden gelabeld met "data-toegang: <veld>"
- Grensoverschrijdende gegevensoverdracht is verboden; **alle data-export moet via een beoordeling van grensoverschrijdende gegevensoverdracht** (neem contact op met de compliance-afdeling)
- Algoritmische beslissingen (kredietverlening / verzekeringstarifering / antifraude) moeten een menselijke reviewpoort behouden
- Modelwijzigingen vereisen algoritmeregistratie; het registratienummer moet in de PR-beschrijving worden vermeld

### 2.3 Zakelijke rode lijnen
- Wijzigingen in risicobeheer-drempels vereisen dubbele handtekening van risicoverantwoordelijke + business-eigenaar
- Operaties die klantgelden raken, moeten een idempotent ontwerp + rollback bij falen hebben
- Transactielimieten, tarieven en productparameters worden beheerd via het parameterbeheerplatform; geen hardcoding in code

## 3. Technologiestack en beperkingen
- **Talen**: Java 17 (kern) / Kotlin (nieuwe modules) / SQL (database)
- **Framework**: Spring Boot 3.x + Spring Cloud Alibaba
- **Database**: OceanBase 4.x (MySQL-compatibiliteitsmodus), **externe sleutels verboden**
- **Interface-standaarden**: intern altijd gRPC; externe interfaces via OpenAPI 3.0; RESTful alleen voor beheerinterfaces
- **Naamgevingsconventies**: Java-klassen in PascalCase, methoden in camelCase, constanten in UPPER_SNAKE; tabelnamen `t_<domein>_<entiteit>`; indexen `idx_<tabel>_<veld>_<volgorde>`
- **Pakketstructuur**: `com.<bedrijf>.<domein>.<subdomein>.<laag>` (bijv. `com.bank.pay.tx.core.service`)

## 4. Coderichtlijnen
- **Minimale testdekking**: kritieke keten ≥ 80%, utility-klassen ≥ 60%, nieuwe code in PR's moet tests bevatten
- **Verplicht te testen paden**: alle controllers vereisen integratietests (inclusief faalpaden); alle enum-takken vereisen unit-tests
- **Verboden paden**: het wijzigen van de map `<legacy-modules>` is verboden — eerst een adapterlaag aanmaken
- **Afhankelijkheidsbeheer**: nieuwe externe afhankelijkheden vereisen SCA-scan + goedkeuring beveiliging

## 5. Bedrijfsregels (per domein)
### 5.1 Transacties
- Limiet per transactie: <bedrag>; daglimiet: <bedrag>; overschrijding vereist handmatige goedkeuring
- Transactietijdsvenster: <HH:MM> ~ <HH:MM>
- Dubbele transactie-detectie: binnen <tijdsvenster> met hetzelfde <veld> = duplicaat

### 5.2 Risicobeheer
- Prioriteit zwarte lijst-matching: interne zwarte lijst → door toezichthouder uitgegeven lijst → gerechtelijke bevriezing
- Uitvoerdrempel antifraude-model: <score>; overschrijding vereist handmatige tweede review

### 5.3 Facturering
- Tariefswijzigingen vereisen een versienummer + ingangsdatum
- Historische orders worden berekend tegen het tarief dat gold op de ingangsdatum, zonder terugwerkende kracht

## 6. Compliancevereisten
- MLPS niveau 3: <evaluatie-instelling>, <datum volgende evaluatie>
- Beoordeling van grensoverschrijdende gegevensoverdracht: toepassingsgebied (alleen modulen voor grensoverschrijdende activiteiten)
- Algoritmeregistratie: toepassingsgebied (kredietverlening / verzekeringstarifering en andere kritieke algoritmen), registratienummer `<registratienummer>`
- Regelgevende rapportage: veldtoewijzingstabel voor <toezichthouder (CBIRC / People's Bank of China)> bevindt zich in `<pad>`

## 7. AI-gebruiksrichtlijnen
- **Scenario's waarin AI is toegestaan**: CRUD-sjablonen, genereren van unit-tests, documentconcepten, SQL-optimalisatiesuggesties
- **Scenario's die handmatige review vereisen**: risicobeheerlogica, factureringsregels, toegangscontrole, versleuteling/ontsleuteling, grensoverschrijdende data
- **Scenario's die AI niet zelfstandig mag afhandelen**: Change Advisory Board (CAB)-goedkeuringsmaterialen, uitvoering van productiewijzigingen, incidentrespons
- **Regels voor gegevensuitvoer**: trainingsdata / prompts / uitvoerlogs mogen het land niet verlaten; gelokaliseerde implementaties (<leverancier>) hebben de voorkeur
- **Auditvereisten**: alle door AI gegenereerde code moet in de PR-beschrijving worden gemarkeerd met "AI-assisted: <toolnaam>"

## 8. Leveranciersbeheer
- **Leverancierstoelating**: SOC 2 / ISO 27001-rapport vereist; AI-modellen moeten een modelkaart verstrekken
- **Contractuele bepalingen**: data-eigendom, modelleerbaarheid, uitstapclausule, auditrecht
- **Auditmechanisme**: kwartaalaudit van AI-gebruik door leveranciers; maandelijkse audit voor hoogrisico-leveranciers

## 9. Beheer en updates
- **Eigenaar**: <governancecommissie> (compliance + beveiliging + architectuur + business)
- **Updatefrequentie**: kwartaalreview; spoedwijzigingen via snel kanaal (dubbele handtekening + 24-uurs publicatie)
- **Wijzigingslog**: zie `CLAUDE_CHANGELOG.md`
- **Overtredingsafhandeling**: eerste overtreding = waarschuwing + verplichte training; tweede overtreding = schorsing AI-tools; derde = intrekking rechten

Dit raamwerk is geen “standaardantwoord”, maar een “invulmal”. Wat elke lege plek invult, is belangrijker dan hoeveel tekst je schrijft — de lege plekken onthullen precies datgene waar jouw organisatie “niet goed over heeft nagedacht”.

Een typisch voorbeeld: bij een middelgrote commerciële bank bevat het CLAUDE.md-bestand specifieke regels voor wachtwoordverwerking — wanneer AI gegenereerde code met wachtwoorden te maken heeft, moet het interne sleutelbeheer-API worden aangeroepen en is hardcoding verboden. Dit soort regels vormt een groot aandeel in de redenen waarom wijzigingen worden afgewezen bij compliancebeoordelingen.

Een belangrijk nieuw veld in H1 2026 is Skills/workflowdefinities — niet alleen documentatie, maar een toolchain die door AI kan worden aangeroepen. Het Skills-systeem van Claude Code (in februari 2026 toegevoegd aan de officiële Anthropic-marktplaats, 112.000 stars op GitHub) maakt processen zoals “Excel-bestanden lezen”, “SQL genereren” en “datamigraties uitvoeren” tot deelbare workflows. Dit is de cruciale evolutie van regeldriven werken in H1 2026: regels zijn niet alleen beperkingen, maar uitvoerbare workflows.

Fase drie: institutionalisering (doorlopend).

Het opstellen van een goede codestandaard is geen eindpunt, maar een beginpunt. Je moet er een vast onderdeel van de organisatieprocessen van maken:

  • CI-gate-integratie: automatisch controleren of code voldoet aan de standaard (bijvoorbeeld detectie van hardcoded wachtwoorden of ongecodeerde gevoelige velden)
  • Gedeelde teamconfiguratie: gebruik het Skills-systeem zodat het hele team met dezelfde standaard werkt
  • Periodiek updatemechanisme: als de regels veranderen, moet de standaard mee veranderen (kwartaalreview)
  • Meting en feedback: volg het defectpercentage van AI-code, het slagingspercentage van compliance-reviews en de herbewerkingsgraad
  • Agent-governance: breid governance van mensen uit naar AI-agents — wat Atos doet met Agent 365 is precies dat: dit op “systeemniveau” brengen in plaats van op “individueel niveau”

Zowel EY als Atos hebben in H1 2026 de derde fase als “organisatorische capaciteit” ingericht. EY’s besparing van 2,5 miljoen uur is te danken aan het goed uitvoeren van fase één en drie — fase twee was slechts het vertalen van regels naar door AI leesbare documenten.

Vijf. Variant voor sterk gereguleerde sectoren: drie engineering-benaderingen voor ingebedde compliance

In sterk gereguleerde sectoren zoals financiën, telecom en gezondheidszorg kent de implementatie van een standaard één extra horde vergeleken met de generieke industrie: compliance is geen externe toevoeging aan het proces, maar ingebouwd in de code. De volgende drie benaderingen zijn in H1 2026 gevalideerde manieren om compliance in te bedden. CIO’s en digitaliseringsverantwoordelijken kunnen ze direct gebruiken als referentie bij het inrichten van de organisatie.

5.1 Compliance-vertegenwoordigers ingebed in stream-teams: compliance als aanwezigheid, niet als goedkeuring achteraf

De traditionele aanpak: het business-team schrijft code, het compliance-team beoordeelt achteraf — en tegen de tijd dat de review problemen aan het licht brengt, is de code al twee weken in productie, met herstelkosten van 2 tot 4 weken. De kern van het probleem is dat compliance aan het einde van het proces zit.

De nieuwe aanpak: een compliance-vertegenwoordiger wordt ingebed in elk stream-aligned team, via een dual reporting-lijn: formeel onder de compliance-afdeling, functioneel onder het business-team. Concreet ziet dat er zo uit:

  • Formatie: één compliance-vertegenwoordiger per 6–8 stream-teams, aangestuurd door de compliance-afdeling, maar fysiek gehuisvest bij het business-team — geen ‘detachering’ voor een paar dagen
  • Functionele KPI’s: 50% van de beoordeling van de compliance-vertegenwoordiger hangt af van de ‘compliance-defectratio’ en het ‘first-time approval-percentage’ van het business-team, niet alleen van de ‘auditdekking’ van de compliance-afdeling
  • Vroegtijdige betrokkenheid: de compliance-vertegenwoordiger neemt deel aan de dagelijkse stand-up (één keer per week is voldoende), beoordeelt pull requests, en AI-gegenereerde code moet vóór de merge door de compliance-vertegenwoordiger worden goedgekeurd — niet pas achteraf wanneer het probleem al is ontdekt
  • Tooling: de compliance-vertegenwoordiger gebruikt Skills-aanroepen met compliance-checklists, in plaats van handmatig elke regel na te lopen

Typisch scenario: een landelijke commerciële bank laat in de eerste helft van 2026 drie streamteams piloten met een ingebedde compliance-vertegenwoordiger, waardoor het percentage afgekeurde AI-code daalt van 35% naar 8% — de kern is niet dat compliance “strenger kijkt”, maar dat compliance “eerder kijkt”. Het cruciale punt hierbij is dat de dotted-line targets van de compliance-vertegenwoordiger zijn afgestemd op de businessdoelstellingen — als de KPI’s van de compliance-vertegenwoordiger nog steeds uitsluitend door de compliance-afdeling worden bepaald, is het inbedden gedoemd te mislukken.

5.2 Compliance als enabling team: van beperkingen naar affordances

De traditionele aanpak: het compliance-team fungeert als “poortwachter”, en het business-team ziet compliance als “lastpak”. Beide partijen spelen een zero-sum-spel.

De nieuwe aanpak: het compliance-team wordt geherstructureerd volgens het enabling team-model van Team Topologies — ze schrijven geen code, ze beoordelen geen pull requests, maar ze leveren drie dingen waarmee het business-team zichzelf kan “complyen”:

  1. Nalevingscontroles in de CI-pipeline: Maak veelvoorkomende nalevingspunten zoals hardcoded wachtwoorden, onversleutelde gevoelige velden, grensoverschrijdende datatransmissie en algoritmische besluitvormingspunten tot verplichte poortwachters in GitHub Actions / GitLab CI. Een PR van het ontwikkelingsteam activeert automatische controles; bij niet-naleving wordt de build direct afgekeurd — zonder dat een compliance-medewerker handmatig alles hoeft door te lopen.
  2. Regelgeving omzetten in affordances (omgevingsgestuurde beperkingen): Bijvoorbeeld: bij het ontwikkelen van functionaliteiten die klantdata verwerken, toont de IDE-plugin een melding als “Voor dit veld wordt aanbevolen KMS aan te roepen”; bij het schrijven van logs wordt automatisch gedetecteerd of er gevoelige informatie in zit en wordt er een melding gegenereerd. Maak naleving een “vanzelfsprekende handeling tijdens het ontwikkelen”, niet “pas bij de release te horen welke regels er zijn overtreden”.
  3. Gedeelde Skills-bibliotheek + compliance-training: Het compliance-team onderhoudt een set “compliance-Skills” die direct kan worden opgeroepen bij onboarding van nieuwe medewerkers of bij overstap tussen teams — compliance-kennis wordt zo omgezet van “documentatie” naar “uitvoerbare tools”.

Typisch scenario: Een regionale bank lanceerde in H1 2026 CI-compliancepoortwachters en IDE-compliancemeldingen, waarmee de gemiddelde tijd voor AI-code-compliancebeoordeling per persoon werd teruggebracht van 45 minuten per beoordeling naar 8 minuten per beoordeling. De kern is niet dat compliance-“beoordeling sneller gaat”, maar dat AI bij het genereren al “geen fouten maakt”.

5.3 Tweesneldheidscompliance: gelaagde afstemming op het bedrijfstempo

Het laatste detail: compliance moet niet met één maat worden gemeten. Verdeel de regels in twee niveaus op basis van risico:

  • Hoogrisicoregels (met betrekking tot klantgelden / algoritmische beslissingen / grensoverschrijdende data / kernbeveiligingsnormen) volgen een strikte goedkeuringsprocedure: verplichte menselijke review + AI-bevestiging in tweede instantie + registratie bij de Change Advisory Board
  • Laagrisicoregels (CRUD-sjablonen / toolcode / documentatiegeneratie) volgen een selfservice-goedkeuringsprocedure: geautomatiseerde CI-checks volstaan, geen menselijke review nodig

Het control plane van Atos’ Agent 365 is in essentie deze gelaagdheid — verschillende niveaus van agents zijn gekoppeld aan verschillende governance-eisen. Door complianceregels op risico te classificeren, ervaren business teams dat compliance niet overal knelpunten oplevert.

De gezamenlijke conclusie van deze drie punten: compliance inbedden is geen extra processtap, maar een herontwerp van de structuur en prikkels van het team. Als je compliance-afdeling nog in de “achteraf controleren”-modus zit, zal de adoptie van normgedreven werken stranden op de moeilijkste fase: institutionalisering. De compliance-afdeling moet eerst transformeren, pas dan kan normgedreven werken binnen business teams soepel draaien.

6. Vragen die je misschien hebt

“We hebben al coderingsstandaarden — wat is het verschil?”

Coderingsstandaarden gaan over “hoe schrijf je code”; normgedreven werken gaat over “hoe werk je samen met AI”. Coderingsstandaarden omvatten geen: bedrijfsregels, compliance-eisen, AI-gebruiksbeleid. Normgedreven werken maakt het volledige proces van mens-AI-samenwerking expliciet; het is geen codeerstijlgids.

“Vertraagt het schrijven van richtlijnen de ontwikkelsnelheid?”

Op korte termijn wel, op lange termijn niet. De data van CodeRabbit geeft een duidelijk antwoord: onbeperkte AI-code heeft een ongeveer 1,7 keer hoger risico op defecten en 2,74 keer meer kans op beveiligingskwetsbaarheden. In de financiële sector kost één nalevingsreview en herstelwerk 2 tot 4 weken — één teruggedraaide review bespaart je genoeg tijd om een maand aan richtlijnen te schrijven. De 250 miljoen dollar die EY bespaarde, is concreet bewijs dat dit werkt als je het organiseert als een organisatorische capaciteit.

“Wat als niemand in ons team weet hoe we richtlijnen moeten schrijven?”

Je hoeft niet vanaf nul te beginnen. GitHub Spec Kit, Claude Code Superpowers en AWS Kiro bieden allemaal templates. Je hoeft alleen de regels in te vullen die specifiek zijn voor jouw organisatie — meestal zijn dat compliance- en beveiligingsregels, en die heeft de compliance- of securityafdeling allang opgeschreven. Ze staan alleen nog niet op een plek waar AI ze kan lezen.

“Er zijn zoveel AI-tools. Welke moeten we kiezen?”

Niet belangrijk. Kies gewoon wat jullie al gebruiken. De standaard is leidend, niet het tool — CLAUDE.md werkt in Claude Code, Cursor én Codex; AGENTS.md draait in de OpenAI-omgeving; constitution.md is model-onafhankelijk. Het gaat om het vastleggen van de standaard, niet om het wisselen van tools. EY rolt uit binnen het Microsoft-ecosysteem, Atos ook — het verschil in toolkeuze is slechts oppervlakkig, de uniformiteit van het governance-raamwerk is waar het echt om draait.

“In augustus 2026 treedt de EU AI Act volledig in werking — raakt dat ons?”

Ja. De EU AI Act treedt op 2 augustus 2026 volledig in werking en stelt verplichte nalevingseisen aan AI-systemen met een hoog risico (waaronder kredietverlening, verzekeringsprijzen, wervingsselectie en kritieke infrastructuur) — risicobeheer (Art. 9), datagovernance (Art. 10), documentatietransparantie (Art. 11–13), menselijk toezicht (Art. 14) en nauwkeurigheid/robuustheid (Art. 15). De boetes kunnen oplopen tot 35 miljoen euro of 7% van de wereldwijde omzet. Voor Chinese bedrijven die internationaal opereren, is de Europese markt een verplichte opgave; voor binnenlandse bedrijven geldt dat het raamwerk van de EU AI Act wereldwijd het meest wordt gerefereerd als standaard — je kunt er misschien niet direct onder vallen, maar je ontkomt er moeilijk aan dat het doorwerkt naar je leveranciers, partners en grensoverschrijdende activiteiten (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

“Nationaal contrast: Europa reguleert AI — wat regelen wij?”

In China draait de governance van generatieve AI om een drietrapsraket: “algoritmeregistratie + datacorpusbeoordeling + veiligheidsevaluatie”, met de Tussentijdse Maatregelen voor het Beheer van Generatieve AI-diensten (van kracht sinds augustus 2023) als centrale pijler. Het grootste verschil tussen beide systemen zit niet in de detaillering van de bepalingen, maar in de reguleringsfilosofie:

DimensieEU AI ActChinese Mededeling over het Beheer van Generative AI-diensten
Juridische statusHorizontale wetgeving (van toepassing op alle AI-systemen)Verticale regels (gericht op generatieve AI-diensten)
Risicoclassificatie4 niveaus (onaanvaardbaar / hoog / beperkt / minimaal)2 niveaus (gerelateerd aan publieke opinieveiligheid / algemeen commercieel gebruik)
ToezichtsmomentVooraf (registratie al bij ontwikkeling)Achteraf (registratie na lancering + algoritme-registratie)
TransparantieHoog (vereist openbaarmaking van samenvatting van trainingsdatabronnen, modelkaarten)Gemiddeld (vereist compliance van trainingsdata, maar geen verplichte openbaarmaking van bronnen)
Maximale boete7% van wereldwijde omzet of €35 miljoenOpschorting van dienst / boete (doorgaans een veelvoud van illegaal verkregen winst)
ToepassingsbereikAlle bedrijven binnen de wereldwijde omzetdrempelAlle entiteiten die diensten aanbieden binnen China

In de praktijk worden AI-systemen van financiële instellingen in China doorgaans door drie regelgevingskaders tegelijk gebonden — de Generatieve AI-beheermaatregelen (basellaag) + de Regeling voor internetleningen door commerciële banken (bedrijfslaag) + de Dengbao-beoordeling (classificatiebeveiligingstest) + algoritmeregistratie (nalevingslaag). Dit betekent dat je voor een regelgedreven aanpak in China het EU AI Act-kader niet klakkeloos kunt kopiëren; je moet de drie binnenlandse lijnen — “corpus-compliance + algoritmeregistratie + toezichtsrapportage” — allemaal in CLAUDE.md verwerken.

Voor bedrijven die internationaal opereren: de vier pijlers van de EU AI Act — “risicobeheer + datagovernance + documentatietransparantie + menselijk toezicht” — zijn ook de richting waar de Chinese toezichthouder geleidelijk naartoe beweegt. De terugkoppelingen op generatieve AI-registraties van de CAC (Cyberspace Administration of China) in 2025 leunen al merkbaar op de granulariteit van de EU-aanpak. Wie vandaag een EU AI Act-compatibele standaard schrijft, zit over drie jaar vrijwel zeker ook goed bij de aanscherpende Chinese regelgeving (CAC-registratieaankondigingen 2025–2026; eu-ai-act compliance 2026.6).

7. Lessen voor beslissers

Les één: het schrijven van een CLAUDE.md/AGENTS.md-projectstandaard is de engineering-actie met het hoogste ROI in het AI-tijdperk.

De investering is 3–8 weken ordeningstijd + 1–2 weken documentatietijd. De opbrengst: een bovengrens van circa 1,7× op defectrisico, 2,74× minder beveiligingskwetsbaarheden, en meer dan 40% minder herbewerking. In de financiële sector dekt één bespaarde compliance-reviewcyclus (2–4 weken) al deze kosten. EY heeft met 150.000 medewerkers op Copilot 250 miljoen dollar bespaard — maar alleen omdat er eerst duidelijke standaarden waren.

Inzicht 2: Standaardgedreven werken is een organisatorisch vermogen, geen toolkeuze.

Of je nu kiest voor GitHub Spec Kit of Claude Code maakt niet uit. Waar het om gaat: heb je gedefinieerd hoe jouw organisatie met AI samenwerkt? Zonder die definitie laat je met het beste gereedschap alleen maar sneller meer technische schuld ontstaan.

Inzicht 3: Leg standaarden vast in organisatieprocessen, niet bij individuen.

Als een standaard alleen in het hoofd van een senior engineer zit, is hij weg zodra die persoon vertrekt. Je moet hem vastleggen in repository-documentatie, CI-gates, gedeelde teamconfiguratie en agent-governanceplatforms. Maak van standaarden een organisatorisch bezit, geen persoonlijke vaardigheid. Atos draait met 19.000 agents in 54 landen, omdat governance daar geen kwestie is van ‘iemand die het snapt’, maar van ‘het systeem dat het afdwingt’.

Inzicht 4: Gates zijn belangrijker dan snelheid.

GitHub Spec Kit’s five-phase gating, Superpowers’ “no code before a failing test,” Kiro’s “can’t start without a spec”—all of these put a brake between AI and the final output. The more capable AI becomes, the earlier governance needs to kick in. The 78% incident rate in the New Relic 2026 report is the price paid by the 62% of teams that ship without review. CIOs in financial services know this better than anyone: your Change Advisory Board (Change Advisory Board (CAB)), your algorithm filing process, your MLPS assessments—all of these are gates before production. AI-generated code needs the same kind of gating, and it has to sit even earlier in the pipeline.

Reverse self-check (no sugarcoating): How often does compliance review bounce back AI-generated code? What was the last incident caused by AI-written code? If you ask your tech lead “how do we collaborate with AI,” can they produce a document on the spot? If you can’t answer even one of these three, spec-driven development hasn’t landed yet—write the spec first, buy the tools second.

Three coaching questions for decision-makers

Three questions to close with—not a checklist, but something you can use directly in your next conversation with your team:

  1. “Als alle AI-tools morgen zouden verdwijnen, hoeveel zou de kwaliteit van jullie code dan dalen?” — Deze vraag legt de werkelijke waarde van specificatiegedreven ontwikkeling bloot: als het antwoord “aanzienlijk” is, zijn jullie specificaties nog niet voldoende verankerd; als het antwoord “vrijwel ongewijzigd” is, draait specificatiegedreven ontwikkeling al op volle toeren.
  2. “Is compliance binnen jullie specificatiegedreven project een ‘poortwachter’ of een ‘enabler’?” — Als het antwoord “poortwachter” is, wordt jullie implementatiesnelheid geflest door review-flessenhalzen; als het antwoord “enabler” is, volgen jullie al de juiste route uit sectie 5.2.
  3. “Hoe zal de omvang van jullie team over 12–18 maanden veranderen?” — Microsofts WTI 2026 geeft als antwoord dat 82% van de leiders AI-agenten zal inzetten om het personeelsbestand te “schalen”. Als jullie antwoord “ongewijzigd” is, groeit je bedrijf niet, of blijft je organisatieontwerp achter bij de voordelen van specificatiegedreven ontwikkeling.

Er zijn geen standaardantwoorden op deze drie vragen. Maar de richting van het antwoord is belangrijker dan het antwoord zelf.

Volgende stap

Dit is het zesde deel in de serie “Software-engineering in transitie in het AI-tijdperk”. Van Conway (organisatie bepaalt architectuur) naar Team Topologies (hoe ontwerp je organisaties), naar de verschuiving van de bottleneck (de bottleneck ligt bij validatie, niet bij codering), en vandaag over specificatiegedreven ontwikkeling (documentatie als sturingsmechanisme voor AI-gedrag).

In het volgende (zevende) deel bekijken we de onderliggende infrastructuur die dit alles mogelijk maakt: het MCP-protocol (Model Context Protocol). Waarom het door Anthropic geopenbaarde protocol wordt omschreven als ‘de USB-C van AI’, waarom OpenAI, Google en Microsoft allemaal zijn gevolgd, en hoe het interoperabiliteit tussen meerdere tools en meerdere agents mogelijk maakt.

Wil je dit gedachtegoed binnen jouw organisatie toepassen?

Wanneer normgedreven ontwikkeling zijn intrede doet in een bedrijf, draait het meestal om een paar concrete vraagstukken: hoe leg je de kernregels vast in CLAUDE.md / AGENTS.md, hoe breng je bestaande code in lijn met de normen, hoe integreer je compliance, en met welke indicatoren evalueer je de pilot.

We bieden drie vormen van samenwerking aan:

  • Interne training: aan de hand van de echte projecten van jouw bedrijf werken we aan het opstellen van normdocumentatie, het ontwerpen van CI-gates, het inbedden van compliance en het opzetten van governancemechanismen.
  • Gericht adviestraject: gericht op één concrete beslissing, zoals ‘moeten wij eerst CLAUDE.md / AGENTS.md opstellen?’ of de prioritering van compliance-aanpassingen in bestaande code.
  • Managementpresentaties en lezingen: over AI-programmeertools, normgedreven ontwikkeling, organisatorische governance en Frontier Firms.

Artikelen kunnen een algemeen raamwerk bieden, maar concrete implementatie vereist maatwerk op basis van de compliance-eisen, regelgevingsgrenzen, technische volwassenheid en bestaande delivery-processen van uw organisatie. Voor samenwerking kunt u contact opnemen via coach@iaiuse.com.

Verder lezen: “Zie de merkrichtlijnen v1.0” (Langzaam AI leren 187), een systematische introductie van het 7-stappenkader voor AI-transformatie in bedrijven.

Over deze serie

“Software-engineering in het AI-tijdperk” is een onderzoeksreeks voor CIO’s, CDO’s, CTO’s en digitaliseringsverantwoordelijken in sectoren zoals telecom, financiën, productie en e-commerce. De serie omvat 18 delen en richt zich op hoe AI-programmeertools, normgedreven ontwikkeling en organisatorisch bestuur van invloed zijn op softwareleveringsprocessen, organisatiestructuren en technische volwassenheid.

De serie volgt voortdurend academische papers, leveranciersdocumentatie en brancherapporten. De onderzoeksdatabase bevat inmiddels meer dan 200 bronnen, en bij elke belangrijke conclusie wordt het bewijsniveau aangegeven, met een duidelijk onderscheid tussen geverifieerde feiten, leveranciersclaims, sectorobservaties en de eigen redenering van de auteur.

Ik heb bijna 8 jaar ervaring in consultancy en businessanalyse voor grote ondernemingen, onder meer bij IBM, waar ik betrokken was bij projecten in telecom, financiën, verzekeringen en productie. Daarna ben ik actief geweest in de frontlinie van productontwikkeling voor telecomoperators, internetproducten en AI-toepassingen, met focus op requirementsanalyse, productontwerp en cross-functionele implementatie.

Deze serie over normgedreven bestuur, organisatorische governance en engineering-oordelen is gebaseerd op deze praktijkervaringen, gekruist met publiek beschikbaar onderzoek en branchecases. Alle projectdetails zijn geanonimiseerd; sommige branchescenario’s betreffen typerende probleemanalyses. De onderbouwing staat in de referenties onderaan.

Achter deze nieuwsbrief zit eigenlijk een klein team — ik en 1-2 collega’s met wie ik langdurig samenwerk. We verdelen het werk over AI-programmeertools-onderzoek, organisatorische governance-casestudies en coachingsgesprekken. De meeste projecten waar we in de teksten “met bedrijven doorheen zijn gegaan”, hebben we samen opgeleverd. Cliëntgerelateerde compliancegrenzen en namen blijven onvermeld; de anonimiteit blijft behouden om ruimte te laten voor toekomstige samenwerkingscollega’s.

Referenties (alle geverifieerd, met per item de bewijsklasse vermeld)

  • CodeRabbit (2025.12). State of AI vs Human Code Generation Report. AI-gegenereerde code bevat 1,7 keer meer problemen dan door mensen geschreven code (10,83 vs 6,45 problemen per pull request), logica/correctheid 1,75×, codekwaliteit 1,64×, beveiliging 1,57×, wachtwoordverwerking 1,88×, XSS 2,74×. Bewijsniveau: primair. Bron: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263

  • The Register (2025.12.17). Verslag over het volledige CodeRabbit-rapport: analyse van 470 open-source pull requests, AI-ondersteunde PR’s bevatten 10,83 problemen versus 6,45 bij puur menselijke code. Bewijsniveau: secundair. Bron: zelfde URL als hierboven

  • CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap” — 2026 wordt het keerpunt van “snelheid van codegeneratie” naar “codekwaliteit en governance”. Bewijsniveau: secundair. Bron: https://tfir.io/ai-code-quality-2026-guardrails

  • New Relic (2026). The 2026 State of AI Coding Report. 78% van de teams ervaart meer incidenten na het live gaan van AI-code; 62% van de technisch leiders geeft toe dat hun team AI-code “vol vertrouwen zonder review” uitrolt; 96% vindt observeerbaarheid essentieel. Bewijsniveau: primair (leveranciersrapport). Bron: https://newrelic.com/resources/report/2026-state-of-ai-coding

  • Microsoft 2026 Work Trend Index Annual Report (2026.5.5). Een enquête onder 20.000 AI-werknemers, verspreid over 10 landen; 82% van de leiders is van plan om binnen 12-18 maanden AI-agents in te zetten om hun personeelsbestand uit te breiden; 81% verwacht een matige tot grote integratie van AI-agents; 24% heeft al een implementatie op bedrijfsniveau; 49% van de Copilot-gesprekken ondersteunt cognitief werk; 58% van de AI-gebruikers doet “dingen die een jaar geleden onmogelijk waren”, en onder Frontier Professionals stijgt dit percentage naar 80%. Bewijsniveau: niveau één. Bron: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf

  • Microsoft FY26-terugblik: van AI-experimenten naar baanbrekende transformatie (28-07-2026). EY rolt Microsoft 365 Copilot uit naar 150.000 medewerkers, wat 2,5 miljoen uur en circa 250 miljoen dollar bespaart; de uitbreiding naar 400.000 wereldwijde medewerkers levert 95% versnelling, 37% lagere financiële operationele kosten en tot 90% minder handmatige workflows op. Atos implementeert Copilot bij 56.000 medewerkers in 56 landen, plus 19.000 AI-agents, met een uniform besturingsvlak voor identiteit, beveiliging, compliance en governance. Bewijsniveau: niveau 1 (officiële Microsoft-terugblik). Bron: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Atos Group en Microsoft Strategische Samenwerking (2026.6.9). Atos implementeert Microsoft 365 E7 (Frontier Suite) voor 56.000 medewerkers in 56 landen, plus 19.000 AI-agents; met een uniform controleplatform voor Entra/Defender/Intune/Purview/Agent 365. Bewijsniveau: niveau één (gezamenlijk persbericht). Bron: 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 (open source in Sept 2025, evolving through H1 2026). Five-stage gating /speckit.constitution → /specify → /plan → /tasks → /implement, plus /clarify /analyze; model-agnostic (works with Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code). Evidence level: primary. Source: https://github.com/github/spec-kit

  • AWS Kiro (released July 2025, evolving through H1 2026). Three-stage workflow: requirements → design → tasks; the spec triggers predefined agent actions; without a spec, you can’t even start. Evidence level: primary. Source: https://kiro.dev/

  • OpenAI Codex + AGENTS.md + Skills (2025-2026). Codex 2026.6 wekelijks 5+ miljoen actieve gebruikers, waarvan 20% geen ontwikkelaars; AGENTS.md + Skills als combineerbare instructiesets. Bewijsniveau: niveau 1 (officiële aankondiging OpenAI). Bron: https://developers.openai.com/codex/skills

  • Claude Code (Anthropic, 2026 H1). CLAUDE.md + .claude/rules/ + Skills-systeem; in 2026.2 opgenomen in de officiële Anthropic-marktplaats; Skills-repository op GitHub met 112.000 sterren; in 2026.2 bekendgemaakt in G-ronde: 2,5 miljard dollar aan jaarlijkse terugkerende omzet. Bewijsniveau: niveau 1. Bron: https://code.claude.com/docs/en/claude-directory

  • JetBrains AI Pulse Survey (2026.1). Onderzoek onder 10.000+ professionele ontwikkelaars wereldwijd, gelokaliseerd in 8 talen; Claude Code CSAT 91% / NPS 54 (hoogste in de sector); Claude Code adoptie op de werkvloer 18% (6x gestegen van 3% in 9 maanden), in Noord-Amerika 24%; Copilot 29% adoptie op de werkvloer maar groei stagneert; Cursor 18%. Bewijsniveau: niveau 1. Bron: https://www.jetbrains.com/lp/tools/ai-tools/

  • Pragmatic Engineer Newsletter (2026.2). Onderzoek onder 15.000 ontwikkelaars; 46% kiest Claude Code als “meest geliefd”, Cursor 19%, Copilot 9%. Bewijsniveau: niveau 1. Bron: https://newsletter.pragmaticengineer.com/

  • Alibaba Qoder (aug 2025 → juli 2026). In augustus 2025 uitgebracht door Alibaba; op 15 mei 2026 is Qoder 1.0 geüpgraded naar een Autonomous Agent Development Workbench; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; op 28 mei 2026 Cloud Agents (managed agent runtime); op 21 juli 2026 Qoder Security; in mei 2026 wereldwijd meer dan 5 miljoen gebruikers; integratie met DingTalk CLI; op 20 mei 2026 is Tongyi Lingma hernoemd naar Qoder CN. Bewijsniveau: primair. Bron: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525

  • vibecoding.app / thebcms.com / tfir.io (2026 H1). Spec Kit-commando’s in vijf fasen, vergelijkende evaluatie van SDD-tools, EARS-notatiemethode. Bewijsniveau: niveau twee (evaluatie door derden). Bron: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development

  • EU AI Act / Code of Practice (volledig van kracht vanaf 2 augustus 2026). De nalevingsdeadline voor AI-systemen met een hoog risico is 2 augustus 2026; bestaande GPAI-modellen hebben uitstel tot 2 augustus 2027; boetes tot 35 miljoen euro of 7% van de wereldwijde omzet; Art. 9-15 betreffen risicobeheer, datagovernance, documentatietransparantie, menselijk toezicht en nauwkeurigheid/robuustheid. Bewijsniveau: niveau één (wetgeving + secundaire nalevingsanalyse). Bron: 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). 44% van de problemen is terug te voeren op ontbrekende context. Bewijsniveau: niveau twee (leveranciersrapport). Bron: https://www.qodo.ai/reports/state-of-ai-code-quality/

Slowly leren AI: De toekomst van AI in de telecom, financiële en manufacturingsector

Als CIO of besluitvormer in de telecom, financiële of manufacturingsector, bent u waarschijnlijk geconfronteerd met de uitdagingen van de toepassing van Artificial Intelligence (AI). In dit artikel zullen we de toekomst van AI in deze sectoren bespreken en enkele voorbeelden geven van hoe AI kan worden toegepast.

Wat is AI?

AI is een breed begrip dat omvat alle technologieën die computers in staat stellen om te leren en te handelen op basis van gegevens. AI kan worden ingedeeld in verschillende categorieën, waaronder Machine Learning (ML), Natural Language Processing (NLP) en Computer Vision.

Toepassingen van AI in de telecomsector

In de telecomsector kan AI worden toegepast op verschillende manieren, zoals:

  • Predictief onderhoud: AI kan worden gebruikt om te voorspellen wanneer apparaten uitvallen of hoeveel capaciteit nodig is om te voldoen aan de vraag.
  • Klantenservice: AI kan worden gebruikt om klanten te helpen met hun vragen en problemen.
  • Netwerkbeheer: AI kan worden gebruikt om netwerken te beheren en te optimaliseren.

Toepassingen van AI in de financiële sector

In de financiële sector kan AI worden toegepast op verschillende manieren, zoals:

  • Risicobeheer: AI kan worden gebruikt om risico’s te identificeren en te beheersen.
  • Kredietbeoordeling: AI kan worden gebruikt om kredietbeoordelingen te doen en te optimaliseren.
  • Transactiebeheer: AI kan worden gebruikt om transacties te beheren en te optimaliseren.

Toepassingen van AI in de manufacturingsector

In de manufacturingsector kan AI worden toegepast op verschillende manieren, zoals:

  • Productieplanning: AI kan worden gebruikt om productieplanningen te doen en te optimaliseren.
  • Kwaliteitscontrole: AI kan worden gebruikt om kwaliteitscontroles te doen en te optimaliseren.
  • Logistiek: AI kan worden gebruikt om logistieke processen te beheren en te optimaliseren.

Een voorbeeld van AI-toepassing

Een voorbeeld van AI-toepassing is de toepassing van AI in de telecomsector door AT&T. AT&T heeft AI gebruikt om te voorspellen wanneer apparaten uitvallen en hoeveel capaciteit nodig is om te voldoen aan de vraag. Dit heeft geleid tot een verbetering van de kwaliteit van de dienstverlening en een vermindering van de kosten.

Conclusie

AI is een krachtig hulpmiddel dat kan worden gebruikt om de prestaties van organisaties in de telecom, financiële en manufacturingsector te verbeteren. Door AI toe te passen op verschillende manieren, zoals predictief onderhoud, klantenservice, netwerkbeheer, risicobeheer, kredietbeoordeling, transactiebeheer, productieplanning, kwaliteitscontrole en logistiek, kunnen organisaties hun prestaties verbeteren en hun kosten verlagen.

Bronnen

Aanbevelingen

  • Lees meer over AI en zijn toepassingen in de telecom, financiële en manufacturingsector.
  • Overweeg om AI toe te passen in uw organisatie.
  • Lees meer over de resultaten van AI-toepassingen in de telecom, financiële en manufacturingsector.
]]> AI-codefouten 1,7×, beveiligingslekken 2,74× — AI ziet uw regels niet. Spec Kit, Kiro, Codex, Claude Code, Qoder gaan 2026 H1 over op CLAUDE.md. 【Spec-Driven】Spec-Driven Development — pisanie specyfikacji to najwyższy ROI w inżynierii AI. Zmiana inżynierii oprogramowania w erze AI — Ucz się AI Powoli 177 https://iaiuse.com/pl/posts/spec-driven-development-najwyzszy-zwrot-z-inwestycji-w-erze-ai 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z

Źródła danych w artykule: CodeRabbit 2025.12 / New Relic 2026, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. Przykłady to uogólnione scenariusze reprezentatywne, nie odnoszą się do konkretnych firm.

Twój największy błąd to nie brak narzędzi, tylko brak pliku CLAUDE.md

CIO jednego z banków komercyjnych narzekał mi się: narzędzia AI kupione, modele wdrożone, ludzie przeszkoleni – a w całym pierwszym półroczu 2026 czas dostarczania oprogramowania praktycznie się nie zmienił. Szef zespołu systemów core bankingowych poszedł dalej: „Kod generowany przez AI nadaje się do użycia, ale i tak trzeba go za każdym razem pisać od nowa – bo model nie zna naszych reguł bankowych, nie zna wymogów regulacyjnych i nie wie, jak się integrować z tym 30-letnim systemem legacy.”

Problem nie leży w tym, że AI nie jest wystarczająco dobre — chodzi o to, że nie spisaliście zasad. Analiza 470 open-source’owych PR-ów przeprowadzona przez CodeRabbit w grudniu 2025 r. dostarczyła zestawu liczb, które szeroko cytowano: PR-y tworzone przy współpracy z AI zawierają średnio 10,83 problemów, podczas gdy PR-y czysto ludzkie — 6,45. To 1,7 raza więcej, czyli o 70% więcej bugów niż w przypadku pracy człowieka. W 2026 r. obraz się nie odwrócił: New Relic w swoim 2026 State of AI Coding Report wykazał, że 78% zespołów raportuje więcej incydentów po wdrożeniu kodu generowanego przez AI, a 62% liderów technicznych przyznaje, że ich zespoły „z pełnym przekonaniem wdrażają kod od AI bez przeglądu linia po linii” (oficjalny raport New Relic 2026, wynik 0,866, źródło pierwszorzędne). Obie grupy danych mówią o tym samym — AI nie brakuje możliwości, brakuje mu kontekstu.

W sierpniu 2026 r. każdą narrację o „przyspieszaniu transformacji AI” trzeba rozpatrywać w kontekście jednego zestawienia:

| Obóz | Postępy (H1 2026) | Kontrprzykłady (H1 2026) |
|—|—|—|—|
| EY | Microsoft 365 Copilot wdrożony dla 150 000 pracowników, oszczędność 2,5 mln godzin / 250 mln USD; planowana ekspansja do 400 000 pracowników na świecie | Jednocześnie przyznają, że 95% przyspieszenia i 37% redukcji kosztów operacyjnych w finansach jest możliwe tylko przy „najpierw standaryzacja procesów” |
| Atos | Wdrożenie w 54 krajach / dla 56 000 pracowników; równolegle działa 19 000 agentów AI pod wspólną warstwą kontroli tożsamości, bezpieczeństwa, zgodności i ładu korporacyjnego | Świadomie trzymają się zasady „najpierw dojrzałe mechanizmy zarządzania Agent 365, potem skalowanie” |
| Samo Microsoft | Work Trend Index 2026: 82% liderów planuje w ciągu 12–18 miesięcy rozszerzyć siłę roboczą o agentów AI | W tym samym raporcie przyznają, że „tempo zmian organizacyjnych nie nadąża za adopcją indywidualną” — to sedno sprzeczności w koncepcji Frontier Firm |

Źródło: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5; New Relic 2026 State of AI Coding Report.

To zestawienie pokazuje jedną rzecz: bez reguł, skalowanie to mnożenie ryzyka przez N. „Szybkość” EY/Atos/Microsoft nie wynika z modeli — wynika z tego, że „organizacja najpierw odpowiedziała sobie na pytanie, jak używać AI”. To właśnie dlatego Spec-Driven Development (SDD) stał się w H1 2026 naprawdę mainstreamowy — nie dlatego, że inżynierowie lubią dokumentację, ale dlatego, że bez specyfikacji nie da się już przetrwać w środowisku z 19 000 agentów.

Ten artykuł wyjaśnia trzy rzeczy: 1) dlaczego defekty w kodzie generowanym przez AI są ponad 1,7 razy poważniejsze niż te pisane przez ludzi; 2) jak pięć platform — GitHub, AWS, OpenAI, Anthropic, Alibaba — w H1 2026 zmierza do tego samego paradygmatu: ograniczania zachowań AI za pomocą dokumentacji; 3) dlaczego spec-driven development to kompetencja organizacyjna, a nie wybór narzędzia — oraz trzy fazy wdrożenia w H1 2026.

Kod AI vs kod ludzki: rozkład defektów (analiza 470 PR-ów open source) Raport CodeRabbit 2025.12 | wszystkie liczby = wielokrotność AI / człowiek (linia bazowa 1.0)

Długość słupka = krotność defektów AI względem ludzkich; linia bazowa 1.0× = poziom ludzki

Linia bazowa 1.0×

Łączna liczba problemów

1.7×
AI 10.83 vs człowiek 6.45 / PR

Błędy logiczne / poprawnościowe

1.75×

Jakość kodu / utrzymywalność

1.64×

Znaleziska bezpieczeństwa (łącznie)

1.57×

Nieprawidłowe obsługiwanie haseł

1.88×

Podatność XSS

2.74×
↑ Najwyżej

Kod AI bez ograniczeń normatywnych wypada gorzej w każdym wymiarze
Finanse / telekom = zgodność, hasła, szyfrowanie pól wrażliwych — AI tego nie widzi

I. Wysoki wskaźnik błędów AI to nie problem modelu, tylko problem kontekstu

W raporcie CodeRabbit jedno zdanie jest cytowane szczególnie często: „AI nie zna logiki biznesowej: model wnioskuje o wzorcach kodu na podstawie statystyk, a nie rozumienia semantyki. Bez ścisłych ograniczeń pomija reguły systemowe, które starsi inżynierowie mają zinternalizowane.”

To zdanie wyjaśnia, dlaczego platforma programistyczna CodeRabbit (firma specjalizująca się w przeglądach kodu przez AI) zobaczyła te dane wcześniej niż inni — codziennie analizują tysiące pull requestów i widzą, jak wygląda kod pisany przez AI. „Najważniejsze” odkrycie to nie suma, ale rozkład:

  • Logika/poprawność +75%: błędy logiki biznesowej, błędne zależności, błędy przepływu sterowania, błędy konfiguracji — tego typu problemy nie zawsze wychodzą w testach, ale w produkcji potrafią skończyć się awarią.
  • Jakość kodu +64%: niespójne nazewnictwo, nieczytelna struktura, łamanie wzorców projektowych — to „kategoria o największych różnicach”. Starszy inżynier od razu widzi: „to nie jest styl, w jakim piszemy u nas”.
  • Bezpieczeństwo +57% (XSS najwyższe, 2,74×): nieprawidłowe obsługiwanie haseł (1,88×), niebezpieczne odwołania do obiektów (1,91×), wycieki wrażliwych informacji, niebezpieczna deserializacja (1,82×) — w sektorze finansowym to nie jest kwestia „czy się nada”, tylko „czy można to w ogóle wypuścić”.

Problem nie w tym, że AI nie jest wystarczająco dobre. Problem w tym, że nie widzi.

Wracając do realnego punktu zapalnego tego CIO – trzy konkretne awarie AI w systemach rdzenia finansowego:

Po pierwsze, AI nie widzi 30-letniej logiki uzgodnień. Reguły ryzyka w banku są zapisane w procedurach składowanych systemu rdzenia – napisane 30 lat temu, nikt ich już nie pamięta w całości. Wygenerowany przez AI kod logicznie wygląda poprawnie, ale w środowisku produkcyjnym wyzwala tę zapomnianą kontrolę uzgodnień, co powoduje odrzucenie całej partii transakcji.

Po drugie, AI nie widzi ograniczeń compliance. Hasła muszą przechodzić przez system zarządzania kluczami, wrażliwe pola muszą być szyfrowane, logi nie mogą zawierać danych klientów – to twarde wymogi regulacyjne, zapisane w wewnętrznych politykach. AI o nich nie wie – kod, który generuje, działa, ale nie przechodzi przeglądu zgodności.

Po trzecie, AI nie widzi twojego długu technicznego. Ten 30-letni system hostowy używa własnego protokołu interfejsowego, a dokumentacja dawno zaginęła. AI pisze kod według standardowego RESTful – po wdrożeniu okazuje się, że interfejsy nie pasują. Dwa tygodnie przeróbek.

Wracając do drugiego zestawu liczb z New Relic: 62% zespołów „z pewnością siebie wdraża kod AI bez przeglądu”, a 78% raportuje więcej incydentów po wdrożeniu. Te dwie liczby razem mówią wprost – problemem nie jest sam wskaźnik defektów w kodzie AI, tylko to, że „nie wiem, jakie defekty ma kod AI”.

Typowy scenariusz: pewien bank akcyjny wdrożył wspomagane przez AI tworzenie modułu kontroli ryzyka w systemie core banking. W ciągu trzech miesięcy odsetek odrzuceń w przeglądzie zgodności znacząco wzrósł. Głównym problemem były wewnętrzne zasady dotyczące zarządzania hasłami, szyfrowania pól wrażliwych, zgodności logów itp. Zasady te były opisane w wewnętrznej dokumentacji, ale AI ich nie widziała. Gdy zespół zapisał kluczowe reguły w pliku CLAUDE.md, odsetek odrzuceń wyraźnie spadł.

Dwa. Pięć głównych platform w 2026 H1: różne drogi, wspólny cel — „sterowanie regułami”

W lipcu 2025 GitHub wydał Spec Kit, a na początku 2026 AWS Kiro, OpenAI Codex i Anthropic Claude Code uzupełniły swoje funkcje; w maju 2026 Alibaba Qoder wpisał „Spec-Driven Workflow” w swoją pozycję produktową. Pięć głównych platform w 2026 H1 osiągnęło ten sam paradygmat — używanie dokumentacji do ograniczania zachowań AI. To nie jest wynalazek jednej firmy, ale zbiorowa odpowiedź branży na „kryzys jakości kodu generowanego przez AI”.

Ścieżki zgodności dla pięciu platform (2025–2026 H1) GitHub Spec Kit Open source 2025.9 constitution.md Pięciostopniowe bramkowanie: constitution → specify → plan → tasks → implement Niezależny od modelu, obsługuje 8+ agentów Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md Trzystopniowy przepływ pracy: Wymagania → projekt → zadania Spec-driven wbudowane w IDE Hooki wyzwalają automatycznych agentów Wbudowane hooki zgodności/audytu Bez speca nie wystartuje OpenAI Codex 2025-2026 AGENTS.md + System Skills Komponowalne zestawy instrukcji Wspólna konfiguracja zespołowa 5M+ tygodniowo (2026.6) 20% nie-programistów Od programowania do uniwersalnego agenta Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + Umiejętności (oficjalny rynek 2026.2) + Ekosystem MCP CSAT 91% / NPS 54 $2.5B ARR（2026.2） GitHub 112 tys. gwiazdek Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Tryb Quest — samodzielne wykonywanie + Tryb Ekspert — zespół + RepoWiki — kontekst 5 mln+ użytkowników na świecie (2026.5) 2026.7.21 Qoder Security CLI DingTalk zintegrowany Wspólny paradygmat: zapisanie „jak współpracujemy z AI” jawnie jako dokument w repozytorium Wszyscy ludzie i wszystkie agenty AI pracują według tej samej specyfikacji — to istota podejścia specyfikacyjnego

Przyjrzyjmy się najnowszym działaniom każdej platformy w 2026 H1:

GitHub Spec Kit: implementacja referencyjna, pięcioetapowa brama kontroli. Udostępniony jako open source we wrześniu 2025 r., do pierwszej połowy 2026 r. stał się de facto implementacją referencyjną w branży. 5 podstawowych komend + 2 uzupełniające: /speckit.constitution (zasady niepodlegające negocjacjom), /speckit.specify (co i dlaczego), /speckit.plan (jak zmienić), /speckit.tasks (podział na zadania), /speckit.implement (wykonanie), plus /clarify i /analyze. Kluczową cechą projektu jest niezależność od modelu — te same pliki spec/plan/tasks nie są przypisane do żadnego konkretnego agenta wykonawczego. Mogą z nich korzystać Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf i Qwen Code. Dzięki temu Spec Kit stał się „protokołem SDD na poziomie organizacji”, a nie produktem zamkniętym w ekosystemie GitHuba (wg vibecoding.app, czerwiec 2026, wynik 0,816, źródło drugorzędne).

AWS Kiro: Wpisz specyfikację wprost do IDE. Premiera w lipcu 2025, a w H1 2026 ewolucja do pełnoprawnego agentowego IDE. Praca przebiega w trzech fazach: wymagania → projekt → zadania. Różnica względem Spec Kit leży w „hakach” – pliki spec w Kiro potrafią wyzwalać zdefiniowane wcześniej akcje agenta, wbudowując kroki wymagające systemów zewnętrznych (zgodność, audyt, wdrożenie) bezpośrednio w przepływ pracy. Jeśli chcesz zmusić zespół do pisania specyfikacji, wybierz Kiro – bo bez pliku spec Kiro po prostu nie wystartuje (oficjalne materiały AWS Kiro, lipiec 2025; dokumentacja Kiro.dev, 2026).

OpenAI Codex: AGENTS.md + komponowalne Skills. W latach 2025–2026 to właśnie AGENTS.md wysunęło się na centrum całego ekosystemu. Kluczowym rozszerzeniem pierwszej połowy 2026 roku są Skills – czyli gotowe, złożone z mniejszych kroków procedury, takie jak „odczyt pliku Excel”, „wygenerowanie zapytania SQL” czy „przeprowadzenie migracji danych”, które można wywoływać jak klocki LEGO. Tygodniowa liczba aktywnych użytkowników Codexa przekroczyła w czerwcu 2026 roku 5 milionów, z czego 20% to osoby niebędące programistami – to często pomijany sygnał: podejście oparte na specyfikacjach przestało być domeną wyłącznie zespołów inżynierskich. Stało się sprawą całej organizacji – product managerowie, zespoły operacyjne i compliance również piszą własne pliki AGENTS.md (ogłoszenie OpenAI z 2.06.2026; recenzja thebcms.com, 2026, wynik 0.801).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic nazywa swój plik z instrukcjami projektu CLAUDE.md (wprowadzony na oficjalny rynek w lutym 2026), .claude/rules/ (reguły podzielone według katalogów) oraz Skills (współdzielone przepływy pracy). Claude Code to narzędzie o najwyższym wskaźniku zadowolenia deweloperów w pierwszej połowie 2026 roku — badanie JetBrains 2026.1 podaje CSAT na poziomie 91% i NPS 54, co potwierdzają dwa niezależne raporty (Pragmatic Engineer 2026.2). To obecnie najwyższy wynik w branży narzędzi AI do programowania (uvik.net 2026.5, wynik 0,956, agregacja źródeł pierwszego rzędu). Claude Code osiągnął w 9 miesięcy przychód roczny w wysokości 2,5 miliarda dolarów (dane z rundy G Anthropic, 2026.2), a repozytorium Skills ma 112 tysięcy gwiazdek na GitHubie — deweloperzy głosują portfelem, co pokazuje realną wartość podejścia opartego na regułach.

Alibaba Qoder: napędzany regulacjami gracz na chińskim rynku. Premiera w sierpniu 2025 r., a 15 maja 2026 r. narzędzie doczekało się wersji 1.0, przechodząc oficjalnie z kategorii „AI IDE” do „Autonomous Agent Development Workbench”. Jego flagowy Spec-Driven Workflow zadebiutował wraz z trybem Quest Mode (autonomiczne zadania wieloplikowe), Expert Mode (równoległa praca zespołu agentów) oraz RepoWiki (grafu wiedzy repozytorium). 28 maja 2026 r. udostępniono Cloud Agents (w pełni zarządzane środowisko uruchomieniowe dla agentów), 21 lipca – Qoder Security (funkcje zgodności i bezpieczeństwa), a w tym samym miesiącu pojawiła się wersja mobilna (Android/iOS/HarmonyOS). Do maja 2026 r. z narzędzia korzystało na świecie ponad 5 mln użytkowników, a CLI DingTalk wymienia Qoder jako jedno z obsługiwanych środowisk wykonywania agentów (Yahoo Finance 2025; Alibaba Cloud official 2026; Baidu Baike 2026.7).

Wspólny paradygmat: jawnie zapisać „jak współpracujemy z AI” w dokumencie, umieścić go w repozytorium i sprawić, by wszyscy — ludzie i agenci AI — pracowali w oparciu o ten sam standard. Szczegóły implementacji różnią się między platformami (nazwy plików / liczba etapów / mechanizmy hooków), ale cel jest identyczny.

Dlaczego to wszystko dzieje się właśnie w H1 2026? Ponieważ próg możliwości AI został już przekroczony — autonomiczni agenci Claude Code, równoległa praca wielu agentów w Codex, refaktoryzacja wielu plików w Cursorze. AI przestało być „narzędziem do autouzupełniania”, a stało się „współpracownikiem”. Dokumenty wdrożeniowe, które dajesz nowemu pracownikowi, muszą być zrozumiałe także dla AI.

III. Sterowanie standardami to kompetencja organizacyjna, nie wybór narzędzia

To najważniejszy punkt dla decydentów. Sterowanie standardami to nie wybór narzędzia, tylko zdefiniowanie „jak nasza organizacja współpracuje z AI”. To, czy wybierzesz GitHub Spec Kit, czy Claude Code, nie ma znaczenia. Liczy się to, czy spisałeś standardy w dokumencie, umieściłeś je w repozytorium i sprawiłeś, że zarówno ludzie, jak i AI pracują w oparciu o nie.

Bez tego nawet najlepsze narzędzia sprawią tylko, że zespół będzie szybciej generować jeszcze więcej długu technicznego.

Umieszczając to w kontekście wdrożeń na szeroką skalę w I połowie 2026 roku, dowody są jeszcze mocniejsze. W retrospektywie fiskalnej za lipiec 2026 roku Microsoft opisał przypadki EY i Atos jako szablon „Frontier Firm” – nie dlatego, że modele są nowe, ale dlatego, że obie firmy najpierw odpowiedziały sobie na pytanie „jak właściwie używać AI”:

EY: najpierw zasady, potem skala. W latach 2024–2025 EY wdrożyło Microsoft 365 Copilot dla 150 tysięcy pracowników, oszczędzając 2,5 miliona godzin i około 250 milionów dolarów. Warunkiem było wcześniejsze zbudowanie ram zarządzania AI: EY zbudowało jednolite środowisko narzędziowe oparte na Power Platform, Copilot Studio, Azure, Foundry i Fabric, osadzając standardy, zgodność i audyt we wspólnej podstawie. Dopiero to umożliwiło późniejsze przyspieszenie o 95%, redukcję kosztów operacji finansowych o 37% i zmniejszenie nawet o 90% pracy ręcznej. Wiceprezes EY podczas AI Tour 2026 ujął to wprost: „Nie wdrażamy AI, żeby potem nadrabiać zarządzanie – najpierw budujemy zarządzanie, a potem wdrażamy AI”.

Atos: jeden płaszczyzna kontroli dla 19 000 agentów. Atos to jedna z pierwszych organizacji na świecie, która wdrożyła Microsoft 365 E7 (Frontier Suite), udostępniając Copilota 56 000 pracowników w 54 krajach. Jednocześnie działa tam 19 000 agentów AI — od wewnętrznego IT, przez jednostki biznesowe, po projekty klienckie — wszystkie budowane na Foundry i Copilot Studio. Kluczem do sukcesu Atos jest „jedna płaszczyzna kontroli”: Entra (tożsamość) + Defender (bezpieczeństwo) + Intune (urządzenia) + Purview (zgodność) + Agent 365 (zarządzanie agentami) — pięć elementów spiętych w jedną całość. To podejście w sektorze finansowym odpowiada połączeniu wymogów typu „MLPS (chiński system klasyfikacji ochrony bezpieczeństwa informacji) + ocena transferu danych za granicę + rejestracja algorytmów + audyt + zarządzanie modelami” — czyli architekturze zarządzczej, a nie zwykłemu narzędziu AI.

Paradoks zmiany organizacyjnej w Microsoft. W raporcie 2026 Work Trend Index Microsoft sam przyznaje: „tempo zmian organizacyjnych pozostaje w tyle za tempem adopcji na poziomie indywidualnym”. Spośród 20 000 ankietowanych użytkowników AI, 82% liderów planuje w ciągu 12–18 miesięcy rozszerzyć siłę roboczą o agentów AI, ale tylko 24% wdrożyło ich już na poziomie całego przedsiębiorstwa. 81% liderów spodziewa się, że agenci AI zostaną w średnim lub dużym stopniu zintegrowani ze strategią AI — ale ponownie tylko 24% już to zrobiło. Oznacza to, że większość firm dzieli od celu 12–18 miesięcy różnicy między „przygotowaniem” a „wdrożeniem”. Kluczowym elementem wypełnienia tej luki jest podejście oparte na regulacjach i standardach (governance).

Źródła: Microsoft FY26 retrospective, 28.07.2026; Microsoft 2026 Work Trend Index Annual Report, 5.05.2026 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, źródło pierwotne PDF); analiza Futurum Group z 26.01.2026 (źródło wtórne).

Wniosek pierwszy: inwestycja w governance to wysoki zwrot z inwestycji.

CodeRabbit dostarcza konkretnych danych do wyliczenia ROI: wskaźnik problemów w kodzie generowanym przez AI jest ok. 1,7× wyższy, a liczba luk bezpieczeństwa spada 2,74×. Co to oznacza w praktyce:

  • Mniej poprawek (w sektorze finansowym jeden przegląd zgodności regulacyjnej to 2–4 tygodnie pracy)
  • Mniej incydentów bezpieczeństwa (kara regulacyjna i utrata reputacji po jednym wycieku danych)
  • Niższe koszty utrzymania (redukcja długu technicznego o 40% to typowa wartość)

Napisanie dobrego pliku CLAUDE.md/AGENTS.md z zasadami projektu to najwyżej oprocentowana inwestycja inżynierska w erze AI. Przykład EY pokazuje to w realnych liczbach — 150 tys. osób korzystających z Copilota przyniosło oszczędności rzędu 250 mln USD. Warto zauważyć: EY nie zaoszczędziło dlatego, że „narzędzie jest świetne”, tylko dlatego, że „dobre praktyki pozwoliły wykorzystać jego potencjał”.

Wniosek drugi: zasady trzeba wpisać w proces organizacyjny, a nie opierać na jednostkach.

Jeśli dobre praktyki siedzą tylko w głowie jednego senior developera, znikną wraz z jego odejściem z zespołu. Trzeba je osadzić w:

  • dokumentacji repozytorium (AGENTS.md / CLAUDE.md / constitution.md)
  • bramkach CI (automatyczna weryfikacja zgodności z zasadami)
  • współdzielonej konfiguracji zespołu (system Skills, który udostępnia je całemu zespołowi)

Niech standardy staną się aktywem organizacji, a nie umiejętnością jednostki. To szczególnie istotne w sektorze finansowym — wymogi compliance, reguły bezpieczeństwa i zasady biznesowe to aktywa na poziomie organizacji, a nie „doświadczenie” pojedynczego inżyniera. 19 000 agentów Atos działa w 54 krajach, ponieważ governance nie polega na tym, że „ktoś to rozumie”, ale na tym, że „system wymusza”.

Wniosek trzeci: bramki kontrolne są ważniejsze niż szybkość.

Pięcioetapowe bramki GitHub Spec Kit (constitution → specify → plan → tasks → implement), zasada Claude Code „nie pisz kodu, zanim testy nie zawiodą” oraz Kiro, które nie wystartuje bez specyfikacji, robią dokładnie to samo: dodają „hamulec” między AI a finalnym rezultatem. Każdy krok pozostawia weryfikowalny artefakt (spec.md, plan.md, tasks.md), który można odrzucić lub zmodyfikować, zanim powstanie kod.

Im bardziej autonomiczne AI, tym bardziej potrzebuje bramek. W sektorze finansowym Change Advisory Board (Change Advisory Board (CAB)), procesy rejestracji algorytmów czy oceny bezpieczeństwa to w istocie bramki dodawane przed wdrożeniem produkcyjnym. Kod generowany przez AI również wymaga podobnych bramek — tyle że w innej formie. Te 62% zespołów z raportu New Relic 2026, które „pewnie wdrażają bez przeglądu”, płaci za tę pewność wyższą liczbą incydentów (78%).

Trzy etapy wdrażania standardów w sektorze finansowym (wersja praktyczna H1 2026) Etap 1: inwentaryzacja reguł 2–4 tygodnie | najwięcej czasu, najwyższy ROI Lista wymogów zgodności (równorzędność/transfer danych/rejestracja) Zasady bezpieczeństwa (hasła/szyfrowanie/logi) Reguły biznesowe (kontrola ryzyka/transakcje/rozliczenia) Ograniczenia techniczne (stare interfejsy/limity wersji) Zarządzanie dostawcami (umowy/audyty/odpowiedzialność) Zebranie rozproszonych reguł Uporządkowanie w dokumentację strukturalną Etap drugi: wdrożenie do repozytorium 1-2 tygodnie | do repozytorium, AI automatycznie ładuje CLAUDE.md / AGENTS.md constitution.md Definicje Skills (współdzielone przepływy pracy) Projekt procesu bramkowania (pięć etapów) .claude/rules/ (reguły warstwowe) Umieszczenie reguł w repozytorium, AI automatycznie ładuje Etap trzeci: instytucjonalizacja Ciągły | od narzędzia do zdolności organizacyjnej Bramka CI (automatyczny przegląd) Wspólna konfiguracja zespołu (Skills) Mechanizm regularnych aktualizacji (przegląd kwartalny) Metryki (wskaźnik defektów / wskaźnik zgodności) Zarządzanie agentami (Agent 365 poziom pierwszy) Standardy stają się aktywem organizacji, Niezależność od jednostek

Pierwszy etap jest najbardziej czasochłonny, ale ROI jest najwyższy
W większości instytucji finansowych zasady są rozproszone w dokumentach/e-mailach/umysłach ludzi; pierwsza konsolidacja to nakład 3–8 tygodni

Cztery. Realne trzy fazy wdrożenia w H1 2026

Poniżej ścieżka trzech faz na przykładzie sektora finansowego — pozostałe branże silnie regulowane mogą ją potraktować jako punkt odniesienia. Praktyki EY i Atos z H1 2026 dokładnie odpowiadają tym trzem fazom.

Faza pierwsza: inwentaryzacja reguł (2–4 tygodnie).

To etap najbardziej czasochłonny, ale o najwyższym zwrocie z inwestycji. Polega na zebraniu reguł rozproszonych po całej organizacji:

  • Wymogi compliance: dla sektora finansowego minimalny baseline = klasyfikacja bezpieczeństwa MLPS (chiński system oceny ochrony danych, odpowiednik równoważnych wymogów sektorowych w UE) + ocena transgranicznego transferu danych (odpowiednik mechanizmu z RODO) + rejestracja algorytmów (chiński odpowiednik wymogu przejrzystości algorytmicznej) — jeśli brak któregokolwiek z tych elementów, nie należy wdrażać AI; powyżej tego minimum dochodzą wymogi sprawozdawczości regulacyjnej, ochrona danych klientów, ograniczenia przepływu danych transgranicznych oraz określenie, które dane mogą być udostępniane modelom AI
  • Reguły bezpieczeństwa: zarządzanie hasłami, standardy szyfrowania, obsługa pól wrażliwych, wymogi dot. logów
  • Reguły biznesowe: progi ryzyka, warunki wypłaty odszkodowań, limity transakcyjne, logika rozliczeń
  • Ograniczenia techniczne: interfejsy systemów legacy, nazewnictwo baz danych, wersje frameworków
  • Zarządzanie dostawcami: jak w umowach wymagać od dostawców stosowania naszych standardów i jak audytować ich wykorzystanie AI

Typowy scenariusz: w fazie inwentaryzacji firma maklerska odkrywa, że zasady są rozproszone po dziesiątkach dokumentów Word, wiki w JIRA, prywatnych mailach i arkuszach Excel — dopiero po uporządkowaniu powstaje ustrukturyzowana lista reguł. Atos podchodzi do tego bardziej systematycznie — dzieli zasady na pięć kategorii: „zgodność, bezpieczeństwo, biznes, technologia, dostawcy”, każda z osobnym workflowem zarządzania, wszystkie podpięte do płaszczyzny kontrolnej Agent 365.

To nie jest zadanie techniczne, tylko organizacyjne — musisz posadzić przy jednym stole dział zgodności, bezpieczeństwa i biznesu, a następnie spisać zasady, które wszyscy akceptują. Za pierwszym razem organizacje z sektora finansowego zwykle potrzebują na to 3–8 tygodni — ale to trwały atut organizacji.

Etap drugi: umieszczenie w repozytorium (1–2 tygodnie).

Zasady zebrane w pierwszym etapie zapisujesz w dokumentach i umieszczasz w repozytorium. GitHub Spec Kit używa pliku constitution.md, Claude Code — CLAUDE.md, OpenAI Codex — AGENTS.md, a Alibaba Qoder — Spec Workflow. Nazwy plików są różne, cel jest ten sam — AI ma je załadować w momencie otwarcia repozytorium.

Struktura rekomendowana (główny trend w I połowie 2026 r.):

  • Opis projektu: czym jest ten system, komu służy
  • Zasady niepodlegające negocjacjom: granice bezpieczeństwa, granice zgodności regulacyjnej, granice biznesowe
  • Stack technologiczny i ograniczenia: jaki framework, jaka baza danych, jakie standardy interfejsów
  • Standardy kodowania: konwencje nazewnictwa, struktura katalogów, minimalne wymagania dotyczące pokrycia testami (bez narzucania rytmu TDD — wystarczy jasno określić poziom pokrycia, ścieżki obowiązkowe i ścieżki zabronione; TDD to opcjonalny rytm organizacyjny, a nie twardy wymóg narzucony przez standardy)
  • Reguły biznesowe: logika zarządzania ryzykiem, zasady transakcyjne, zasady rozliczeń
  • Wymagania zgodności: ocena bezpieczeństwa (Dengbao), transfer danych za granicę, raportowanie regulacyjne, czy algorytmy generujące AI wymagają rejestracji
  • Zasady korzystania z AI: w jakich scenariuszach można używać AI, w jakich wymagany jest przegląd manualny, zasady transferu danych za granicę
  • Zarządzanie dostawcami: postanowienia umowne, mechanizmy audytu, podział odpowiedzialności

Załącznik: szkielet CLAUDE.md dla sektora finansowego (ok. 200 linii, gotowy do forka i adaptacji)

Poniżej znajduje się szkielet CLAUDE.md dla modernizacji systemu centralnego banku komercyjnego, zorganizowany według kolejności: „zasady niepodlegające negocjacjom → wymagania zgodności → zasady korzystania z AI → reguły biznesowe → ograniczenia inżynieryjne”. Państwa firma nie musi zaczynać od zera — wystarczy uzupełnić puste pola swoimi konkretnymi zasadami.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
# CLAUDE.md — <nazwa systemu> — specyfikacja współpracy z AI

> Zakres: <nazwa systemu> v<wersja>, wszyscy agenci AI (Claude Code / Cursor / Copilot / Codex)
> pracujący w tym repozytorium muszą przestrzegać niniejszej specyfikacji. Dokument jest utrzymywany przez <komitet zarządzania>, przegląd kwartalny.
> Ostatnia aktualizacja: YYYY-MM-DD

## 1. Przegląd projektu
- **Pozycjonowanie biznesowe**: nazwa systemu core / segmenty klientów / główne typy transakcji
- **Kluczowy łańcuch**: transakcja → kontrola ryzyka → rozliczenie → uzgodnienie → raportowanie
- **Okno niedostępności**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (żadne zmiany nie mogą być wprowadzane)
- **Zależności krytyczne**: system <X> upstream, system <Y> downstream, platforma raportowania regulacyjnego

## 2. Zasady nienegocjowalne (czerwone linie — naruszenie = odmowa merge)

### 2.1 Czerwone linie bezpieczeństwa
- Hasła, klucze i tokeny muszą zawsze przechodzić przez KMS (Key Management Service) — **zakaz hardkodowania**, **zakaz drukowania w logach**
- Wrażliwe pola klienta (numer dowodu tożsamości / numer karty / CVV / telefon) **muszą być szyfrowane przy zapisie**; tekst jawny jest zakazany w bazie
- W logach nie mogą się pojawiać: pełny numer dowodu, pełny numer karty, hasło w jawnej postaci, kombinacja imienia i nazwiska klienta z numerem telefonu
- Wywołania interfejsów zewnętrznych muszą przechodzić przez bramkę API; połączenia bezpośrednie są zabronione

### 2.2 Czerwone linie zgodności
- Kod wygenerowany przez AI, który dotyczy dostępu do danych klientów, musi w opisie PR zawierać adnotację „dostęp do danych: <pole>”
- Transgraniczny transfer danych jest zabroniony; **każde wyprowadzenie danych za granicę wymaga oceny transgranicznego transferu danych** (kontakt z działem zgodności)
- Decyzje algorytmiczne (kredyt / taryfikacja ubezpieczeń / antyfraud) muszą zachować ścieżkę przeglądu ludzkiego
- Zmiana modelu wymaga rejestracji algorytmów; numer rejestracji musi być przywołany w opisie PR

### 2.3 Czerwone linie biznesowe
- Zmiana progów kontroli ryzyka wymaga podwójnego podpisu szefa ryzyka i szefa biznesu
- Operacje dotyczące środków klienta muszą mieć projekt idempotentny + mechanizm rollbacku w razie niepowodzenia
- Limity transakcji, taryfy i parametry produktu przechodzą przez platformę zarządzania parametrami; zakaz hardkodowania w kodzie

## 3. Stos technologiczny i ograniczenia
- **Języki**: Java 17 (core) / Kotlin (nowe moduły) / SQL (baza danych)
- **Framework**: Spring Boot 3.x + Spring Cloud Alibaba
- **Baza danych**: OceanBase 4.x (tryb kompatybilności MySQL), **klucze obce zabronione**
- **Standardy interfejsów**: wewnętrznie wyłącznie gRPC; interfejsy zewnętrzne w OpenAPI 3.0; RESTful tylko dla interfejsów administracyjnych
- **Konwencje nazewnictwa**: klasy Java PascalCase, metody camelCase, stałe UPPER_SNAKE; nazwy tabel `t_<domena>_<encja>`; indeksy `idx_<tabela>_<kolumna>_<kolejność>`
- **Struktura pakietów**: `com.<firma>.<domena>.<pod-domena>.<warstwa>` (np. `com.bank.pay.tx.core.service`)

## 4. Standardy kodu
- **Minimalne pokrycie testami**: łańcuch krytyczny ≥ 80%, klasy narzędziowe ≥ 60%, każdy nowy kod w PR musi zawierać testy
- **Ścieżki obowiązkowo testowane**: wszystkie kontrolery muszą mieć testy integracyjne (w tym ścieżki awarii); wszystkie gałęzie enum muszą mieć testy jednostkowe
- **Ścieżki zabronione**: zakaz modyfikacji katalogu `<historyczne moduły obciążone>` — najpierw utworzyć warstwę adaptacyjną
- **Zarządzanie zależnościami**: każde dodanie zależności zewnętrznej wymaga skanowania SCA + zatwierdzenia bezpieczeństwa

## 5. Zasady biznesowe (wg domeny)
### 5.1 Transakcje
- Limit pojedynczej transakcji: <kwota>; limit dzienny: <kwota>; przekroczenie wymaga zatwierdzenia manualnego
- Okno czasowe transakcji: <HH:MM> ~ <HH:MM>
- Detekcja duplikatów: w <okno czasowe> ten sam <pole> = duplikat

### 5.2 Kontrola ryzyka
- Priorytet dopasowania blacklisty: lista wewnętrzna → lista przekazana przez regulatora → zamrojenie sądowe
- Próg wyjścia modelu antyfraud: <wynik>; powyżej wymagana manualna weryfikacja drugiego poziomu

### 5.3 Rozliczenia
- Każda zmiana taryfy musi mieć numer wersji + datę wejścia w życie
- Zamówienia historyczne rozliczane wg taryfy obowiązującej w dacie wejścia w życie, bez retroaktywności

## 6. Wymagania zgodności
- MLPS poziom 3: <organ regulacyjny>, <data następnej oceny>
- Ocena transgranicznego transferu danych: zakres (tylko moduły działalności transgranicznej)
- Rejestracja algorytmów: zakres (kredyt / taryfikacja ubezpieczeń i inne algorytmy krytyczne), numer rejestracji `<nr rejestracji>`
- Raportowanie regulacyjne: tabela mapowania pól <CBIRC / Ludowy Bank Chin> w `<ścieżka>`

## 7. Standardy użycia AI
- **Scenariusze dozwolone dla AI**: szablony CRUD, generowanie testów jednostkowych, wersje robocze dokumentacji, sugestie optymalizacji SQL
- **Scenariusze wymagające przeglądu ludzkiego**: logika kontroli ryzyka, zasady rozliczeń, kontrola uprawnień, szyfrowanie/deszyfrowanie, dane transgraniczne
- **Scenariusze zabronione do samodzielnego wykonania przez AI**: materiały do zatwierdzenia Change Advisory Board (CAB), wykonanie zmian produkcyjnych, reagowanie awaryjne
- **Zasady wyprowadzania danych**: dane treningowe / prompty / logi wyjściowe — żadne nie opuszczają kraju; preferowane wdrożenia lokalne (<dostawca>)
- **Wymagania audytowe**: każdy kod wygenerowany przez AI musi w opisie PR zawierać oznaczenie „AI wspomagane: <nazwa narzędzia>”

## 8. Zarządzanie dostawcami
- **Kwalifikacja dostawców**: wymagane raporty SOC 2 / ISO 27001; modele AI muszą mieć kartę modelu
- **Klauzule umowne**: własność danych, wyjaśnialność modelu, klauzula wyjścia, prawo audytu
- **Mechanizm audytu**: kwartalny audyt użycia AI przez dostawców; miesięczny audyt dostawców wysokiego ryzyka

## 9. Zarządzanie i aktualizacje
- **Właściciel**: <komitet zarządzania> (zgodność + bezpieczeństwo + architektura + biznes)
- **Częstotliwość aktualizacji**: przegląd kwartalny; zmiany awaryjne w trybie ekspresowym (podwójny podpis + ogłoszenie 24h)
- **Dziennik zmian**: zobacz `CLAUDE_CHANGELOG.md`
- **Obsługa naruszeń**: pierwsze naruszenie = ostrzeżenie + obowiązkowe szkolenie; drugie naruszenie = zawieszenie użycia narzędzi AI; trzecie = cofnięcie uprawnień

Ten szkielet to nie „gotowa odpowiedź”, tylko „szablon do wypełnienia”. Ważniejsze od tego, ile napiszesz, jest to, czym wypełnisz każdą rubrykę — puste miejsca ujawniają dokładnie to, czego wasza firma „nie przemyślała”.

Typowy przykład: w jednym z banków komercyjnych plik CLAUDE.md definiuje konkretne zasady obsługi haseł — gdy AI generuje kod, który dotyka haseł, musi wywoływać wewnętrzne API do zarządzania kluczami, a hardkodowanie jest zabronione. Tego typu reguły stanowią znaczną część powodów zwrotów w przeglądach compliance.

Ważnym nowym elementem w H1 2026 są Skills/definicje workflow — to nie tylko dokumentacja, ale łańcuchy narzędzi, które AI może faktycznie wywoływać. System Skills w Claude Code (trafił do oficjalnego marketplace Anthropica w lutym 2026, 112 tys. gwiazdek na GitHubie) zamienia czynności takie jak „odczyt pliku Excel”, „generowanie SQL” czy „przeprowadzanie migracji danych” w współdzielone workflow. To kluczowa ewolucja podejścia opartego na standardach w H1 2026: standard to nie tylko ograniczenie, ale wykonywalny workflow.

Etap trzeci: instytucjonalizacja (ciągła).

Samo napisanie standardów to nie koniec, to dopiero początek. Trzeba je wbudować w procesy organizacyjne:

  • Bramki CI: automatyczne sprawdzanie, czy kod jest zgodny ze standardami (np. wykrywanie zahardkodowanych haseł, niezaszyfrowanych pól wrażliwych)
  • Współdzielona konfiguracja zespołowa: wykorzystanie systemu Skills, aby cały zespół korzystał z tych samych standardów
  • Mechanizm regularnej aktualizacji: gdy zmieniają się reguły, standardy muszą się zmieniać razem z nimi (przegląd kwartalny)
  • Metryki i informacja zwrotna: śledzenie wskaźnika defektów w kodzie generowanym przez AI, odsetka przejść przeglądów zgodności, wskaźnika poprawek
  • Zarządzanie agentami: rozszerzenie ładu korporacyjnego z ludzi na agentów AI — to, co robi Atos w ramach Agent 365, polega na przeniesieniu tego z poziomu „indywidualnego” na „systemowy”

EY i Atos w H1 2026 obie uczyniły trzeci etap „kompetencją organizacyjną”. Oszczędność 2,5 miliona godzin w EY to zasługa dobrze wykonanego pierwszego i trzeciego etapu — drugi etap to tylko przetłumaczenie reguł na dokumenty czytelne dla AI.

5. Wariant dla branż silnie regulowanych: trzy inżynieryjne podejścia do wbudowania zgodności

W branżach silnie regulowanych — finansach, telekomunikacji, ochronie zdrowia — wdrożenie oparte na standardach ma dodatkowy próg: zgodność nie jest dodatkiem do procesu, lecz elementem wbudowanym w kod. Poniższe trzy podejścia to sprawdzone w H1 2026 sposoby wbudowania zgodności, które CIO i osoby odpowiedzialne za transformację cyfrową mogą wprost wykorzystać przy projektowaniu organizacji.

5.1 Wbudowanie przedstawiciela ds. zgodności w zespół strumieniowy: zgodność „obecna w procesie”, a nie „na końcu procesu”

Tradycyjne podejście: zespół produktowy pisze kod, zespół ds. zgodności przeprowadza kontrolę po fakcie — gdy problem zostaje wykryty, kod jest już w produkcji od dwóch tygodni, a koszt poprawek to 2–4 tygodnie. Sedno problemu: zgodność jest na końcu procesu.

Nowe podejście: w każdym zespole strumieniowym (stream-aligned team) osadzamy przedstawiciela ds. zgodności, w modelu podwójnego raportowania: „liniowo” do działu compliance, „macierzowo” do zespołu biznesowego. Konkretne założenia:

  • Struktura etatowa: 1 przedstawiciel ds. zgodności na 6–8 zespołów strumieniowych; etat należy do działu compliance, ale fizycznie pracuje w zespole biznesowym — to nie jest „delegacja” na zasadzie wyjazdów
  • KPI w linii macierzowej: 50% wagi oceny przedstawiciela ds. zgodności opiera się na „wskaźniku defektów compliance” i „odsetku przejść przeglądu za pierwszym razem” w zespole biznesowym — a nie wyłącznie na „pokryciu audytowym” wg działu compliance
  • Zaangażowanie z wyprzedzeniem: przedstawiciel ds. zgodności uczestniczy w codziennych stand-upach (wystarczy raz w tygodniu), przeglądach PR; kod generowany przez AI musi przejść przez niego przed mergem — a nie być wykryty po fakcie
  • Wsparcie narzędziowe: przedstawiciel ds. zgodności korzysta z list kontrolnych jako Skills (wywołań narzędziowych), zamiast ręcznego odhaczania pozycji

Typowy scenariusz: w pierwszej połowie 2026 roku pewien ogólnokrajowy bank akcyjny wdrożył pilotażowo trzy zespoły streamingowe z wbudowanymi przedstawicielami compliance, obniżając wskaźnik odrzuceń kodu AI pod względem zgodności z 35% do 8% — kluczem nie jest to, że compliance „patrzy surowiej”, ale że „patrzy wcześniej”. Sednem tego podejścia jest to, aby raportowanie pośrednie przedstawicieli compliance było wyrównane z celami biznesowymi — jeśli ich KPI nadal opierają się wyłącznie na zadaniach z działu compliance, osadzenie z góry skazane jest na porażkę.

5.2 Compliance jako enabling team: zamiana ograniczeń w affordance

Tradycyjne podejście: zespół compliance pełni rolę „bramkarza”, a zespoły biznesowe postrzegają go jako „utrudniacza”. Obie strony grają w grę o sumie zerowej.

Nowe podejście: zespół compliance zostaje przebudowany zgodnie z modelem enabling team z Team Topologies — nie pisze kodu, nie przegląda bezpośrednio pull requestów, ale dostarcza trzy rzeczy, które umożliwiają zespołom biznesowym „samodzielne przestrzeganie zgodności”:

  1. Kontrola zgodności w pipeline CI: Wysokoczęstotliwościowe punkty zgodności, takie jak twarde kodowanie haseł, przechowywanie danych wrażliwych w postaci jawnej, transgraniczny transfer danych oraz punkty decyzyjne algorytmów, zamieniane są w obowiązkowe bramki w GitHub Actions / GitLab CI. Pull request od zespołu biznesowego automatycznie wyzwala kontrolę — brak zgodności oznacza natychmiastowe odrzucenie, bez konieczności ręcznego przeglądu przez przedstawiciela ds. zgodności.

  2. Wymogi regulacyjne jako affordance (ograniczenia reagujące na kontekst): Na przykład podczas tworzenia funkcji korzystających z danych klientów wtyczka IDE podpowiada: „To pole zaleca wywołanie KMS”; podczas pisania logów system automatycznie wykrywa, czy zawierają informacje wrażliwe, i generuje alert. Wymogi zgodności stają się „naturalnym elementem procesu tworzenia oprogramowania”, a nie „informacją o naruszeniu na etapie wdrożenia”.

  3. Współdzielona biblioteka Skills + szkolenia z zakresu zgodności: Zespół ds. zgodności utrzymuje zestaw „Skills zgodności”, z którego można korzystać podczas onboardingu nowych pracowników lub przy zmianie zespołu — wiedza o zgodności przestaje być „dokumentacją”, a staje się „narzędziem wykonywalnym”.

Typowy scenariusz: pewien bank regionalny wdrożył w H1 2026 bramki zgodności w CI oraz podpowiedzi zgodności w IDE, skracając średni czas przeglądu zgodności kodu AI z 45 minut na 8 minut na przypadek. Kluczowe nie jest to, że „przegląd zgodności stał się szybszy”, ale to, że kod generowany przez AI „od razu jest poprawny”.

5.3 Zgodność dwubiegowa: dopasowanie do tempa biznesu

Ostatni szczegół: compliance nie może być „szyte na jedno kopyto”. Podziel reguły na dwa poziomy ryzyka:

  • Reguły wysokiego ryzyka (dotyczące środków klientów / decyzji algorytmicznych / danych transgranicznych / twardych wymogów bezpieczeństwa) objęte ścisłą kontrolą dostępu: wymagany przegląd manualny + weryfikacja przez AI + wpis do rejestru Change Advisory Board (CAB) (Change Advisory Board)
  • Reguły niskiego ryzyka (standardowy CRUD / kod narzędziowy / generowanie dokumentacji) objęte samoobsługową kontrolą dostępu: wystarczy automatyczna weryfikacja w CI, bez przeglądu manualnego

Płaszczyzna kontrolna Agent 365 w Atos to w istocie ten sam model warstwowy — agenci na różnych poziomach mają przypisane różne wymagania governance. Podział reguł compliance według poziomu ryzyka sprawia, że zespoły biznesowe czują: „compliance nie blokuje mnie na każdym kroku”.

Łączny wniosek z tych trzech kwestii: wbudowanie compliance to nie dodanie kolejnego procesu, tylko przeprojektowanie struktury i mechanizmów motywacyjnych zespołu. Jeśli Twój dział compliance wciąż działa w trybie „kontroli po fakcie”, wdrożenie sterowania regułami utknie na najtrudniejszym etapie — „instytucjonalizacji”. Najpierw compliance musi przejść transformację, żeby zespoły biznesowe mogły płynnie działać w modelu sterowania regułami.

6. Pytania, które możesz sobie zadać

„Mamy już standardy kodowania — czym to się różni?”

Standardy kodowania określają „jak pisać kod”, a sterowanie regułami określa „jak współpracować z AI”. Standardy kodowania nie obejmują: reguł biznesowych, wymogów compliance ani polityk korzystania z AI. Sterowanie regułami to ujęcie w jawną formę całego procesu współpracy człowieka z AI — a nie stylistyczny przewodnik po kodzie.

„Czy pisanie standardów spowolni tempo prac developerskich?”

Krótkoterminowo – tak, długoterminowo – nie. Dane CodeRabbit dają jednoznaczną odpowiedź: nieograniczony regulacjami kod generowany przez AI niesie ze sobą ok. 1,7-krotnie wyższe ryzyko wystąpienia defektów oraz 2,74-krotnie wyższe ryzyko podatności bezpieczeństwa. W sektorze finansowym jeden cykl poprawek po audycie zgodności to 2–4 tygodnie pracy – oszczędzisz sobie jednego takiego cyklu, a zyskany czas wystarczy na spisanie standardów na cały miesiąc. Oszczędności rzędu 250 mln USD w EY to dowód, że wdrożenie tych praktyk na poziomie całej organizacji realnie przekłada się na wyniki biznesowe.

„A co, jeśli w naszym zespole nikt nie umie pisać standardów?”

Nie musisz zaczynać od zera. GitHub Spec Kit, Claude Code Superpowers czy AWS Kiro oferują gotowe szablony. Wystarczy uzupełnić je o reguły specyficzne dla Waszej organizacji – w większości będą to zasady compliance i bezpieczeństwa, które Wasze działy prawne i bezpieczeństwa już dawno spisały. Problem w tym, że nikt dotąd nie umieścił ich w miejscu, do którego AI ma dostęp.

„Na rynku jest tyle narzędzi AI – które wybrać?”

Nieważne. Wybierzcie to, czego już używacie. Reguły są ważniejsze niż narzędzia — CLAUDE.md działa w Claude Code, Cursor i Codex; AGENTS.md zadziała w ekosystemie OpenAI; constitution.md jest niezależny od modelu. Klucz to spisać zasady, a nie zmieniać narzędzia. EY wdraża to w ekosystemie Microsoft, Atos też — różnice w wyborze narzędzi są tylko powierzchowne, liczy się spójne zarządzanie governance.

“W sierpniu 2026 r. w pełni wchodzi w życie unijny akt o sztucznej inteligencji (EU AI Act) — czy to nas dotyczy?”

Tak. EU AI Act wchodzi w pełną fazę egzekwowania 2 sierpnia 2026 r., nakładając obowiązkowe wymogi zgodności na systemy AI wysokiego ryzyka (w tym scoring kredytowy, wyceny ubezpieczeń, selekcję kandydatów do pracy oraz infrastrukturę krytyczną) — zarządzanie ryzykiem (art. 9), governance danych (art. 10), przejrzystość dokumentacji (art. 11–13), nadzór człowieka (art. 14), dokładność/odporność (art. 15). Maksymalne kary sięgają 35 mln EUR lub 7% globalnych przychodów. Dla chińskich firm ekspandujących za granicę rynek UE to obowiązkowy sprawdzian; dla firm działających lokalnie ramy EU AI Act są też najczęściej punktem odniesienia na świecie — możesz nie podlegać im bezpośrednio, ale trudno uniknąć ich wpływu pośredniego na Twoich dostawców, partnerów i działalność transgraniczną (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

„Odpowiednik w Chinach: UE reguluje AI, a co my?”

Krajowe podejście do generatywnej AI opiera się na trzech filarach: „rejestracja algorytmów + kontrola korpusów treningowych + ocena bezpieczeństwa”. Kluczowym aktem prawnym są tymczasowe środki zarządzania usługami generatywnej sztucznej inteligencji, obowiązujące od sierpnia 2023 r. Największa różnica między oboma systemami nie leży w szczegółowości przepisów, ale w filozofii legislacyjnej:

WymiarEU AI ActChińskie „Środki zarządzania usługami generatywnej AI”
Charakter prawnyRegulacja horyzontalna (obejmuje wszystkie systemy AI)Regulacja sektorowa (koncentruje się na usługach generatywnej AI)
Klasyfikacja ryzyka4 poziomy (niedopuszczalne / wysokie / ograniczone / minimalne)2 poziomy (dotyczące bezpieczeństwa opinii publicznej / ogólne zastosowanie komercyjne)
Moment nadzoruEx ante (rejestracja już na etapie opracowywania)Ex post (rejestracja po wdrożeniu + rejestracja algorytmów)
TransparentnośćWysoka (obowiązek publikacji streszczenia źródeł danych treningowych, karty modelu)Średnia (wymóg zgodności korpusów danych, ale bez obowiązku ujawniania źródeł)
Maksymalne kary7% globalnego przychodu lub 35 mln EURZawieszenie usługi / grzywna (zwykle wielokrotność bezprawnego zysku)
Zakres stosowaniaWszystkie przedsiębiorstwa powyżej progu globalnego przychoduWszystkie podmioty świadczące usługi na terytorium Chin

W praktyce systemy AI w chińskich instytucjach finansowych podlegają zwykle trzem równoległym reżimom regulacyjnym — „Środkom zarządzania generatywną AI” (warstwa podstawowa) + „Środkom zarządzania bankowością internetową banków komercyjnych” (warstwa biznesowa) + 等保 (klasyfikacja ochrony bezpieczeństwa informacji) + algorytmiczna rejestracja (warstwa zgodności). To oznacza, że w Chinach nie można mechanicznie przenieść ram EU AI Act — trzy lokalne osie, czyli „zgodność korpusów treningowych + rejestracja algorytmów + raportowanie regulacyjne”, trzeba w całości zapisać w pliku CLAUDE.md.

Dla firm wchodzących na rynek globalny: cztery filary EU AI Act — „zarządzanie ryzykiem + ład danych + przejrzystość dokumentacji + nadzór człowieka” — to kierunek, do którego stopniowo zbliżają się także chińscy regulatorzy. Już w 2025 roku kilka odpowiedzi na zgłoszenia rejestracyjne generatywnej AI wydanych przez Cyberspace Administration of China wyraźnie czerpało z poziomu szczegółowości rozwiązań unijnych. Jeśli dziś piszesz specyfikacje zgodne z EU AI Act, z dużym prawdopodobieństwem będą one kompatybilne również z zaostrzającym się reżimem w Chinach w ciągu najbliższych 3 lat (ogłoszenia o rejestracji CAC 2025–2026; zgodność z EU AI Act czerwiec 2026).

7. Wnioski dla decydentów

Wniosek pierwszy: napisanie specyfikacji projektowej CLAUDE.md/AGENTS.md to najwyższy zwrot z inwestycji w inżynierii w erze AI.

Jego nakładem jest 3–8 tygodni porządkowania + 1–2 tygodnie dokumentacji. Zwrot: górna granica ryzyka defektów ok. 1,7×, luki bezpieczeństwa mniejsze 2,74×, spadek liczby poprawek o 40%+. W sektorze finansowym jedno uniknięcie powtórnego przeglądu compliance (2–4 tygodnie) pokrywa ten koszt. EY wdrożyło Copilota dla 150 tys. osób i zaoszczędziło 250 mln USD — ale pod warunkiem, że najpierw miało uporządkowane standardy.

Wniosek drugi: standaryzacja to kompetencja organizacji, nie wybór narzędzia.

Nieważne, czy wybierzesz GitHub Spec Kit, czy Claude Code. Liczy się to, czy masz zdefiniowane „jak nasza organizacja współpracuje z AI”. Bez tego nawet najlepsze narzędzie sprawi tylko, że zespół będzie szybciej generować dług techniczny.

Wniosek trzeci: zapisz standardy w procesach organizacji, nie polegaj na jednostkach.

Jeśli standardy żyją tylko w głowie jednego seniora, znikną, gdy on odejdzie. Trzeba je osadzić w dokumentacji repozytorium, bramkach CI, współdzielonej konfiguracji zespołu i platformie zarządzania agentami. Standardy mają być aktywem organizacji, nie umiejętnością jednostki. Atos uruchamia 19 000 agentów w 54 krajach, bo governance to nie „ktoś to rozumie”, tylko „system to wymusza”.

Wniosek czwarty: bramki jakości są ważniejsze niż szybkość.

GitHub Spec Kit z pięcioma bramkami etapowymi, zasada Superpowers „nie pisz kodu, dopóki test nie zakończy się porażką”, wymóg Kiro „nie zaczniesz bez specyfikacji” — wszystko to sprowadza się do jednego: hamulec między AI a finalnym rezultatem. Im silniejsze możliwości AI, tym wcześniej musi pojawić się governance. Te 78% awarii z raportu New Relic 2026 to cena, jaką płaci 62% zespołów, które „wdrażają bez przeglądu”. CIO w sektorze finansowym rozumieją to najlepiej: wasz Change Advisory Board (Change Advisory Board (CAB)), proces rejestracji algorytmów, ocena zgodności z wymogami bezpieczeństwa — wszystko to są bramki przed wdrożeniem produkcyjnym. Kod generowany przez AI wymaga podobnych bramek, tyle że postawionych znacznie wcześniej.

Szybki test kontrolny (bez upiększania): czy przegląd zgodności kodu generowanego przez AI często kończy się poprawkami? Jaki był ostatni problem spowodowany przez kod z AI? Jeśli zapytasz lidera technicznego „jak współpracujemy z AI”, czy pokaże ci dokument? Jeśli choć na jedno z trzech pytań nie znasz odpowiedzi, to znak, że podejście oparte na specyfikacjach jeszcze nie wdrożyło się w życie — najpierw specyfikacje, potem narzędzia.

Trzy pytania coachingowe dla decydentów

Na koniec trzy pytania — to nie lista kontrolna, tylko gotowe punkty wyjścia do rozmowy z zespołem:

  1. „Gdyby jutro wszystkie narzędzia AI zniknęły, o ile spadłaby jakość kodu w waszym zespole?” — to pytanie ujawnia realną wartość podejścia sterowanego specyfikacjami. Jeśli odpowiedź brzmi „znacząco”, Twoje standardy nie są jeszcze wystarczająco ugruntowane. Jeśli brzmi „prawie wcale” — specyfikacje już realnie napędzają pracę zespołu.

  2. „Czy w Waszym projekcie opartym na specyfikacjach dział compliance jest ’bramkarzem’ czy ’enablerem’?” — jeśli odpowiedź to „bramkarz”, tempo wdrażania rozwiązań będzie blokowane przez wąskie gardła w procesach zatwierdzania. Jeśli „enabler” — jesteście już na właściwej ścieżce opisanej w sekcji 5.2.

  3. „Jak zmieni się wielkość Waszego zespołu w perspektywie 12–18 miesięcy?” — według raportu Microsoft WTI 2026, 82% liderów planuje „skalować” siłę roboczą za pomocą agentów AI. Jeśli Twoja odpowiedź to „bez zmian”, oznacza to albo brak wzrostu biznesu, albo organizację, która nie nadąża za korzyściami płynącymi ze specyfikacji.

Na te trzy pytania nie ma jednej słusznej odpowiedzi. Ale kierunek, w którym zmierzają Twoje odpowiedzi, jest ważniejszy niż same odpowiedzi.

Co dalej

To szósta część serii o transformacji inżynierii oprogramowania w erze AI. Zaczęliśmy od prawa Conwaya (struktura organizacji determinuje architekturę), przeszliśmy przez Team Topologies (jak projektować zespoły), następnie omówiliśmy przesunięcie wąskiego gardła (z kodowania na walidację), a dziś skupiliśmy się na sterowaniu specyfikacjami (używaniu dokumentacji do kierowania zachowaniem AI).

Następny artykuł (siódmy) przyjrzymy się fundamentowi, na którym to wszystko się opiera — protokołowi MCP (Model Context Protocol): dlaczego otwarty standard od Anthropic nazywany jest „USB-C dla AI”, dlaczego OpenAI, Google i Microsoft wszyscy za nim podążają, oraz jak umożliwia interoperacyjność wielu narzędzi i wielu agentów.

Chcesz wdrożyć to podejście w swojej firmie?

Gdy standardy oparte na regułach trafiają do przedsiębiorstwa, zwykle trzeba rozwiązać kilka konkretnych problemów: jak ująć kluczowe zasady w plikach CLAUDE.md / AGENTS.md, jak uzupełnić standardy w istniejącym kodzie, jak wbudować zgodność z regulacjami oraz jakie wskaźniki przyjąć do oceny pilotażu.

Obecnie oferujemy trzy formy współpracy:

  • Szkolenia wewnętrzne: w oparciu o rzeczywiste projekty w Twojej firmie — opracowanie dokumentacji standardów, zaprojektowanie bramek CI, ścieżki wbudowania zgodności oraz budowa mechanizmów zarządczych.
  • Konsultacje specjalistyczne: skupione na konkretnej decyzji, np. „czy nasza firma powinna najpierw napisać CLAUDE.md / AGENTS.md” lub ustalenie priorytetów dostosowania istniejącego kodu do wymogów.
  • Sesje dla kadry zarządzającej i wystąpienia branżowe: wokół narzędzi AI do programowania, standardów opartych na regułach, zarządzania organizacją oraz firm z czołówki rynku (Frontier Firms).

Artykuł dostarcza uniwersalnych ram, ale konkretne wdrożenie wymaga przeprojektowania w oparciu o wymogi compliance, granice regulacyjne, dojrzałość inżynieryjną i istniejące procesy dostarczania oprogramowania w danej organizacji. Współpraca: coach@iaiuse.com.

Polecana lektura: „Metodologia Znaku Firmowego v1.0” (Learn AI Slowly 187) — systematyczne omówienie 7-etapowych ram transformacji AI w przedsiębiorstwie.

O serii

„Transformacja inżynierii oprogramowania w erze AI” to seria badawcza skierowana do CIO, CDO, CTO oraz liderów transformacji cyfrowej w branżach telekomunikacyjnej, finansowej, produkcyjnej i e-commerce. Cykl obejmuje 18 artykułów, koncentrując się na wpływie narzędzi AI do programowania, podejścia opartego na specyfikacjach oraz ładu organizacyjnego na procesy dostarczania oprogramowania, strukturę organizacyjną i dojrzałość inżynieryjną.

Seria na bieżąco śledzi publikacje naukowe, materiały producentów i raporty branżowe. Baza badawcza obejmuje ponad 200 pozycji, a kluczowe wnioski są opatrzone poziomem dowodowości, aby odróżnić zweryfikowane fakty, deklaracje producentów, obserwacje branżowe od autorskich analiz.

Mam ponad 8 lat doświadczenia w doradztwie dla dużych przedsiębiorstw i analityce biznesowej. Pracowałem w IBM, uczestnicząc w projektach dla sektora telekomunikacyjnego, finansowego, ubezpieczeniowego i produkcyjnego. Następnie rozwijałem się na pierwszej linii — w produktach operatorskich, internetowych i aplikacjach AI — zajmując się analizą wymagań, projektowaniem produktów i wdrożeniami międzyzespołowymi.

Ten artykuł to seria przemyśleń na temat podejścia opartego na regulacjach, ładu organizacyjnego i inżynierii — wywodzących się z praktyki, weryfikowanych krzyżowo z publicznymi badaniami i case studies z branży. Wszystkie treści dotyczące konkretnych projektów zostały zanonimizowane; część scenariuszy branżowych to analiza typowych przypadków, a źródła podano na końcu artykułu.

Za tym blogiem stoi właściwie mały zespół — ja i 1–2 osoby, z którymi długoterminowo współpracuję. Każde z nas odpowiada za inny obszar: badania nad narzędziami AI do programowania, analiza case studies z zakresu ładu organizacyjnego, rozmowy coachingowe. Większość projektów, o których piszemy, że „przeprowadziliśmy firmy przez nie”, to projekty, które realizowaliśmy wspólnie. Nadal nie ujawniamy nazw klientów ani osób — ze względu na granice zgodności i prywatności; anonimowość zostawiamy też jako przestrzeń dla przyszłych współpracowników.

Źródła (zweryfikowane, z określeniem poziomu dowodów dla każdej pozycji)

  • CodeRabbit (2025.12). State of AI vs Human Code Generation Report. Kod generowany przez AI zawiera 1,7× więcej problemów niż kod pisany przez człowieka (10,83 vs 6,45 problemów na PR), w tym: logika/poprawność 1,75×, jakość kodu 1,64×, bezpieczeństwo 1,57×, obsługa haseł 1,88×, XSS 2,74×. Poziom dowodów: pierwszy. Źródło: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263

  • The Register (2025.12.17). Relacja z pełnego raportu CodeRabbit: analiza 470 open-source’owych PR-ów wykazała, że PR-y tworzone przy współpracy z AI zawierają średnio 10,83 problemów, podczas gdy w przypadku czysto ludzkiej pracy jest to 6,45. Poziom dowodów: drugi. Źródło: jak wyżej.

  • CodeRabbit / David Loker (2026.1). „2026 Predictions: The Speed Trap” – rok 2026 to punkt zwrotny: od „szybkości generowania kodu” do „jakości kodu i zarządzania ryzykiem”. Poziom wiarygodności: drugi. Źródło: https://tfir.io/ai-code-quality-2026-guardrails

  • New Relic (2026). The 2026 State of AI Coding Report. 78% zespołów zgłasza więcej incydentów po wdrożeniu kodu napisanego przez AI; 62% liderów technicznych przyznaje, że ich zespoły „z pełnym przekonaniem wdrażają kod AI bez przeglądu”; 96% uważa obserwowalność za niezbędną. Poziom wiarygodności: pierwszy (raport producenta). Źródło: https://newrelic.com/resources/report/2026-state-of-ai-coding

  • Raport roczny Microsoft 2026 Work Trend Index (5.05.2026). Badanie objęło 20 000 pracowników korzystających z AI w 10 krajach; 82% liderów planuje w ciągu 12–18 miesięcy rozszerzyć siłę roboczą o agentów AI; 81% spodziewa się średniego lub dużego stopnia integracji agentów; 24% wdrożyło je już na poziomie całego przedsiębiorstwa; 49% rozmów z Copilot wspiera pracę poznawczą; 58% użytkowników AI twierdzi, że robi rzeczy, które rok wcześniej były poza ich zasięgiem, a wśród profesjonalistów z czołówki (Frontier Professionals) odsetek ten wzrasta do 80%. Poziom wiarygodności: pierwszy. Źródło: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf

  • Retrospektywa Microsoft FY26: od eksperymentów z AI do transformacji na miarę granic możliwości (28.07.2026). Firma EY wdrożyła Microsoft 365 Copilot dla 150 000 pracowników, oszczędzając 2,5 miliona godzin i około 250 milionów dolarów; następnie rozszerzyła wdrożenie na 400 000 pracowników na całym świecie, osiągając 95% przyspieszenia pracy, 37% redukcji kosztów operacyjnych w finansach i nawet 90% redukcji ręcznych przepływów pracy. Atos wdrożył Copilot dla 56 000 pracowników w 56 krajach oraz 19 000 agentów AI, z ujednoliconą płaszczyzną kontroli tożsamości, bezpieczeństwa, zgodności i ładu korporacyjnego. Poziom dowodów: pierwszy (oficjalna retrospektywa Microsoft). Źródło: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Współpraca strategiczna Atos Group i Microsoft (2026.06.09). Atos wdraża Microsoft 365 E7 (Frontier Suite) dla 56 000 pracowników w 56 krajach oraz 19 000 agentów AI; ujednolicona płaszczyzna zarządzania Entra/Defender/Intune/Purview/Agent 365. Poziom wiarygodności: pierwszy (wspólny komunikat prasowy obu firm). Źródło: 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 (open-source 2025.9, evolving through 2026 H1). A 5-stage gated workflow /speckit.constitution → /specify → /plan → /tasks → /implement, plus /clarify /analyze; model-agnostic (works with Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code). Evidence level: primary. Source: https://github.com/github/spec-kit

  • AWS Kiro (released 2025.7, evolving through 2026 H1). A three-stage workflow: requirements → design → tasks; the spec triggers predefined agent actions; without a spec, the workflow won’t start. Evidence level: primary. Source: https://kiro.dev/

  • OpenAI Codex + AGENTS.md + Skills (2025–2026). Codex w czerwcu 2026 r. przekroczył 5 mln aktywnych użytkowników tygodniowo, z czego 20% to osoby niebędące programistami; AGENTS.md + Skills tworzą komponowalny zestaw instrukcji. Poziom wiarygodności: pierwszy (oficjalne ogłoszenie OpenAI). Źródło: https://developers.openai.com/codex/skills

  • Claude Code (Anthropic, I poł. 2026). System oparty na CLAUDE.md + .claude/rules/ + Skills; w lutym 2026 r. trafił do oficjalnego marketplace Anthropica; repozytorium Skills na GitHubie zdobyło 112 tys. gwiazdek; w lutym 2026 r. ujawniono w ramach rundy G 2,5 mld USD rocznych przychodów. Poziom wiarygodności: pierwszy. Źródło: https://code.claude.com/docs/en/claude-directory

  • JetBrains AI Pulse Survey (2026.1). Badanie obejmujące ponad 10 000 profesjonalnych programistów na całym świecie, zlokalizowane na 8 języków; Claude Code CSAT 91% / NPS 54 (najwyższe w branży); wskaźnik adopcji Claude Code w miejscu pracy 18% (wzrost 6-krotny z 3% w ciągu 9 miesięcy), w Ameryce Północnej 24%; Copilot 29% adopcji w miejscu pracy, ale wzrost zatrzymany; Cursor 18%. Poziom dowodów: pierwszy. Źródło: https://www.jetbrains.com/lp/tools/ai-tools/

  • Pragmatic Engineer Newsletter (2026.2). Badanie 15 000 programistów; 46% wybrało Claude Code jako “najbardziej lubiane narzędzie”, Cursor 19%, Copilot 9%. Poziom dowodów: pierwszy. Źródło: https://newsletter.pragmaticengineer.com/

  • Alibaba Qoder (2025.8 → 2026.7). W sierpniu 2025 r. Alibaba wypuściło Qoder; 15 maja 2026 r. Qoder 1.0 ewoluował do Autonomous Agent Development Workbench; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; 28 maja 2026 r. Cloud Agents (zarządzane środowisko uruchomieniowe dla agentów); 21 lipca 2026 r. Qoder Security; w maju 2026 r. ponad 5 mln użytkowników na świecie; integracja z CLI w DingTalk; 20 maja 2026 r. Tongyi Lima została przemianowana na Qoder CN. Poziom wiarygodności: pierwszy. Źródła: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525

  • vibecoding.app / thebcms.com / tfir.io (2026 H1). Polecenia pięcioetapowego Spec Kita, porównanie narzędzi SDD, notacja EARS. Poziom dowodów: drugi (oceny zewnętrzne). Źródło: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development

  • EU AI Act / Code of Practice (pełne wdrożenie od 2.08.2026). Termin zgodności dla systemów AI wysokiego ryzyka upływa 2.08.2026; istniejące modele GPAI mają czas do 2.08.2027; maksymalne kary to 35 mln EUR lub 7% globalnego przychodu; art. 9–15 obejmują zarządzanie ryzykiem, zarządzanie danymi, przejrzystość dokumentacji, nadzór człowieka oraz dokładność i solidność. Poziom dowodów: pierwszy (rozporządzenie + analiza zgodności drugiego poziomu). Źródło: 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). 44% problemów wynika z braku kontekstu. Poziom dowodów: drugi (raport dostawcy). Źródło: https://www.qodo.ai/reports/state-of-ai-code-quality/

Czytaj AI Slowly 001: AI w sektorze telekomunikacji

W dzisiejszym świecie, gdzie technologie AI są coraz bardziej powszechne, CIO i decydenci z sektora telekomunikacji muszą być świadomi możliwości i wyzwań związanych z implementacją AI w swoich organizacjach.

W tym artykule, będziemy omawiać najważniejsze aspekty implementacji AI w sektorze telekomunikacji, w tym:

  • Ocena ryzyka: Jak ocenić ryzyko związane z implementacją AI w swojej organizacji?
  • Zarządzanie danymi: Jak zapewnić bezpieczeństwo i prywatność danych w czasie implementacji AI?
  • Wdrożenie: Jak wdrożyć AI w swojej organizacji, aby osiągnąć oczekiwane wyniki?

Przykład: AT&T, jeden z największych operatorów telekomunikacyjnych na świecie, wykorzystuje AI w swojej sieci do poprawy jakości usług i zwiększenia efektywności.

Zarządzanie ryzykiem: Jak ocenić ryzyko związane z implementacją AI w swojej organizacji?

Wdrożenie AI w organizacji wiąże się z pewnymi ryzykami, takimi jak:

  • Ryzyko technologiczne: Jak zapewnić, że AI będzie działać sprawnie i bezawaryjnie?
  • Ryzyko biznesowe: Jak zapewnić, że AI będzie przynosić korzyści finansowe organizacji?

Zarządzanie danymi: Jak zapewnić bezpieczeństwo i prywatność danych w czasie implementacji AI?

AI wymaga dostępu do dużych ilości danych, aby działać efektywnie. Jednak, aby zapewnić bezpieczeństwo i prywatność danych, należy:

  • Zapewnić bezpieczeństwo danych: Jak zapewnić, że dane będą chronione przed nieuprawnionym dostępem?
  • Zapewnić prywatność danych: Jak zapewnić, że dane będą przetwarzane zgodnie z prawem?

Wdrożenie: Jak wdrożyć AI w swojej organizacji, aby osiągnąć oczekiwane wyniki?

Wdrożenie AI w organizacji wymaga:

  • Planowanie: Jak zaplanować wdrożenie AI w swojej organizacji?
  • Koordinacja: Jak zapewnić, że wszystkie zespoły będą współpracować w celu wdrożenia AI?
  • Monitorowanie: Jak monitorować postępy wdrożenia AI i dostosowywać go do potrzeb organizacji?

Wdrożenie AI w organizacji może przynieść wiele korzyści, takich jak:

  • Poprawa efektywności: Jak AI może pomóc w poprawie efektywności organizacji?
  • Poprawa jakości usług: Jak AI może pomóc w poprawie jakości usług w organizacji?
  • Zwiększenie zysków: Jak AI może pomóc w zwiększeniu zysków organizacji?

W tym artykule, omówiliśmy najważniejsze aspekty implementacji AI w sektorze telekomunikacji. Pamiętaj, że AI może przynieść wiele korzyści, ale również wiąże się z pewnymi ryzykami. Dlatego, aby osiągnąć oczekiwane wyniki, należy odpowiednio ocenić ryzyko, zapewnić bezpieczeństwo i prywatność danych, a także wdrożyć AI w swojej organizacji.

]]> AI: 1,7× więcej błędów, 2,74× więcej luk — bo nie widzi Twoich reguł. Spec Kit, Kiro, Codex, Claude Code, Qoder przechodzą 2026 H1 na CLAUDE.md. 【Спецификация как движущая сила】Spec-Driven Development — написание спецификаций — самое выгодное инженерное действие в эпоху ИИ. Трансформация программной инженерии в эпоху ИИ — Учим ИИ медленно, выпуск 177 https://iaiuse.com/ru/posts/%D1%81%D0%BF%D0%B5%D1%86%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F-%D0%BA%D0%B0%D0%BA-%D0%B4%D0%B2%D0%B8%D0%B6%D1%83%D1%89%D0%B0%D1%8F-%D1%81%D0%B8%D0%BB%D0%B0-spec-driven-development-%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5-%D1%81%D0%BF%D0%B5%D1%86%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D0%B9-%D1%81%D0%B0%D0%BC%D1%8B%D0%B9-%D0%B2%D1%8B%D1%81%D0%BE%D0%BA%D0%B8%D0%B9-roi-%D0%B2-%D1%8D%D0%BF%D0%BE%D1%85%D1%83-ai-%D1%82%D1%80%D0%B0%D0%BD%D1%81%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D1%8F 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z

Источники данных в статье: CodeRabbit 2025.12 / New Relic 2026, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. Кейсы обобщают типичные сценарии и не привязаны к конкретным компаниям.

Ваша главная ошибка — не в том, что вы не купили инструменты, а в том, что не написали CLAUDE.md

CIO одного акционерного банка пожаловался мне: инструменты на базе ИИ купили, модели развернули, людей обучили — а за первое полугодие 2026 сроки поставки практически не изменились. Руководитель группы, отвечающей за ядро системы, выразился ещё жёстче: «Код, который пишет ИИ, рабочий, но каждый раз приходится переписывать его с нуля — он не понимает наших внутренних регламентов, не знает требований регулятора и понятия не имеет, как стыковаться с нашей 30-летней легаси-системой».

Вот перевод вашего Markdown-текста на русский язык в соответствии со всеми вашими требованиями:

Анализ 470 открытых pull request’ов дал группу цифр, на которую часто ссылаются: в среднем в AI-сопровождаемых PR содержится 10,83 проблемы, в чисто ручных — 6,45. Это в 1,7 раза больше, то есть на 70% больше багов, чем при работе человека. К 2026 году сюжет не перевернулся: New Relic в своём «2026 State of AI Coding Report» обнаружил, что 78% команд сообщают о большем количестве инцидентов после выкладки AI-кода в продакшн, а 62% технических лидеров признают, что их команды «уверенно отправляют AI-код без построчного ревью» (официальный отчёт New Relic, 2026, оценка 0,866, первоисточник). Обе группы цифр говорят об одном и том же — у AI нет недостатка в способностях, есть недостаток в контексте.

В августе 2026 года все нарративы об «ускорении AI-трансформации» нужно рассматривать в паре с другим набором фактов:

| Лагерь | Прогресс (1-е полугодие 2026) | Контрпример (1-е полугодие 2026) |
|—|—|—|—|
| EY | Microsoft 365 Copilot развёрнут на 150 000 сотрудников, экономия 2,5 млн часов / 250 млн долларов; масштабирование на 400 000 сотрудников по всему миру | При этом признаёт: ускорение на 95% и снижение операционных затрат в финансовом блоке на 37% достижимы только при условии «сначала регламенты, потом инструменты» |
| Atos | Развёртывание в 54 странах / 56 000 сотрудников; одновременно работают 19 000 ИИ-агентов под единой плоскостью управления идентификацией, безопасностью, комплаенсом и управлением | Жёстко придерживается принципа «сначала вывести на productive контур возможности управления Agent 365, затем масштабировать» |
| Сама Microsoft | Work Trend Index 2026: 82% руководителей планируют в ближайшие 12–18 месяцев расширять штат за счёт ИИ-агентов | В то же время признаёт: «темп организационных изменений отстаёт от темпов индивидуального использования» — это ключевое противоречие в концепции Frontier Firm |

Источник: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5; New Relic 2026 State of AI Coding Report.

Эти два сопоставления показывают одну вещь: без стандартов масштабирование означает умножение риска на N. «Скорость» EY/Atos/Microsoft — это не скорость моделей, а скорость, с которой организация отвечает на вопрос «как мы будем использовать AI». Именно это стало фоном для того, почему Spec-Driven Development (SDD, разработка, управляемая спецификациями) по-настоящему вышел в мейнстрим в первой половине 2026 года — не потому, что инженеры любят документацию, а потому, что без написания спецификаций уже невозможно выжить в среде с 19 000 агентов.

Эта статья проясняет три вещи: 1) почему дефекты в AI-коде встречаются более чем в 1,7 раза чаще, чем в коде, написанном человеком; 2) как пять платформ — GitHub, AWS, OpenAI, Anthropic и Alibaba — в первой половине 2026 года пришли к одной и той же парадигме: ограничение поведения AI с помощью документации; 3) почему спецификационно-ориентированная разработка — это организационная способность, а не выбор инструмента, и какие три этапа внедрения прошли в первой половине 2026 года.

AI-код против человеческого кода: распределение дефектов (анализ 470 открытых PR) Отчёт CodeRabbit 2025.12｜все цифры — кратное отношение AI / человек (базовая линия 1.0)

Длина столбца = во сколько раз дефектов AI больше; базовая линия 1.0× = уровень человека

Базовая линия 1.0×

Общее число проблем

1.7×
AI 10.83 против человека 6.45 / PR

Логические / ошибки корректности

1.75×

Качество кода / поддерживаемость

1.64×

Находки по безопасности (сводно)

1.57×

Неправильная обработка паролей

1.88×

XSS-уязвимости

2.74×
↑ максимум

AI-код без нормативных ограничений выше человеческого по всем параметрам
Финансы/телеком = комплаенс-сверка, управление паролями, шифрование чувствительных полей — AI всего этого не видит

I. Дефекты ИИ — это не проблема модели, а проблема контекста

В отчёте CodeRabbit есть одна фраза, которую цитируют постоянно: «ИИ не понимает локальную бизнес-логику: модель выводит паттерны кода статистически, а не семантически. Без строгих ограничений она упускает системные правила, которые старший разработчик впитал за годы практики».

Эта фраза объясняет, почему собственная AI-платформа CodeRabbit (компания, специализирующаяся на AI-ревью кода) увидела эти данные раньше других — они ежедневно просматривают тысячи pull request’ов и видят, как выглядит код, написанный ИИ. «Ключевой» вывод — не в общих цифрах, а в распределении:

  • Логика/корректность +75%: ошибки бизнес-логики, ошибки зависимостей, ошибки потока управления, ошибки конфигурации — такие проблемы не всегда всплывают в тестах, но приводят к инцидентам в продакшене.
  • Качество кода +64%: несогласованные имена, нечёткая структура, нарушение принятых в проекте паттернов — это «категория с максимальным разрывом». Старший разработчик видит с первого взгляда: «это не наш стиль».
  • Безопасность +57% (XSS-класс — до 2,74×): некорректная обработка паролей (1,88×), небезопасные ссылки на объекты (1,91×), утечка чувствительной информации, небезопасная десериализация (1,82×) — в финансовой отрасли это вопрос не «можно ли использовать», а «можно ли выпускать в продакшен».

Проблема не в том, что ИИ недостаточно силён. Проблема в том, что он не видит.

Вернёмся к реальной боли того самого CIO. Вот три конкретных сбоя ИИ в финансовых системах ядра:

Во-первых, ИИ не видит 30-летнюю логику сверки. Правила риск-контроля банка записаны в хранимых процедурах ядра — написаны 30 лет назад, и никто уже не помнит их полностью. Сгенерированный ИИ код выглядит логично, но в продакшене он задевает ту самую забытую проверку сверки, и вся партия транзакций падает.

Во-вторых, ИИ не видит регуляторных ограничений. Пароли — только через систему управления ключами, чувствительные поля — только в шифрованном виде, логи не должны содержать клиентские данные. Это жёсткие требования регулятора, прописанные во внутренних регламентах. ИИ об этом не знает: код работает, но не проходит комплаенс-проверку.

В-третьих, ИИ не видит ваш технический долг. У той 30-летней хост-системы собственный протокол интерфейсов, документация давно утеряна. ИИ пишет код по стандартному RESTful, а при запуске выясняется, что интерфейсы не сходятся — две недели переделки.

Теперь вернёмся к другим цифрам New Relic: 62% команд «уверенно выкатывают код ИИ без ревью», 78% после релиза сообщают о большем числе инцидентов. Сложите эти два числа — и получится: проблема не в уровне дефектности ИИ-кода как таковом. Проблема в том, что «я не знаю, какие дефекты в этом ИИ-коде».

Типичный сценарий: один из акционерных банков внедрил ИИ-ассистента для разработки модуля контроля рисков в своей основной системе. За три месяца доля отклонений на этапе комплаенс-проверки заметно выросла. Основные проблемы — управление паролями, шифрование чувствительных полей, соответствие логов внутренним правилам. Все эти правила были описаны во внутренней документации, но ИИ их не видел. Когда команда переписала ключевые правила в файл CLAUDE.md, доля отклонений заметно снизилась.

II. Пять платформ в первом полугодии 2026: разные пути, одна цель — «управление через спецификации»

В июле 2025 года GitHub выпустил Spec Kit. В начале 2026 года AWS Kiro, OpenAI Codex и Anthropic Claude Code закрыли этот пробел. В мае 2026 года Alibaba Qoder включил «Spec-Driven Workflow» в своё позиционирование продукта. К первому полугодию 2026 года все пять платформ пришли к одной и той же парадигме — использование документации для управления поведением ИИ. Это не изобретение какой-то одной компании, а коллективный ответ индустрии на «кризис качества кода, создаваемого ИИ».

Нормативные пути пяти платформ (2025–2026 H1) GitHub Spec Kit Открытый исходный код 2025.9 constitution.md Пятиэтапный гейтинг: constitution → specify → plan → tasks → implement Не зависит от модели, 8+ агентов Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md Трёхэтапный рабочий процесс: Требования → Дизайн → Задачи Spec-driven в IDE-процесс Хуки запускают автоагентов Встроенные хуки аудита Без spec не запустится OpenAI Codex 2025-2026 AGENTS.md + Система навыков Комбинируемые наборы команд Общая конфигурация команды 5M+ активных в неделю (2026.6) 20% не разработчиков От кода к универсальному агенту Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + Навыки (официальный маркет 2026.2) + Экосистема MCP CSAT 91% / NPS 54 $2.5B ARR（2026.2） GitHub 112 тыс. звёзд Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Quest Mode автономное выполнение + Expert Mode команда + RepoWiki контекст 5M+ пользователей по всему миру (2026.5) 2026.7.21 Qoder Security CLI DingTalk подключён Общий подход: явно прописать «как мы сотрудничаем с ИИ» в документе и хранить в репозитории Все люди и все ИИ-агенты работают по одному стандарту — суть стандарт-ориентированности

Рассмотрим последние действия каждой платформы в первом полугодии 2026 года:

GitHub Spec Kit: эталонная реализация с пятиэтапным гейткипом. Релиз состоялся в сентябре 2025 года, и уже к первой половине 2026-го проект стал де-факто эталоном в индустрии. 5 основных команд + 2 дополнительных: /speckit.constitution (непреложные принципы), /speckit.specify (что делаем и зачем), /speckit.plan (как меняем), /speckit.tasks (декомпозиция на задачи), /speckit.implement (исполнение), плюс /clarify и /analyze. Ключевая особенность архитектуры — модельная независимость: одни и те же файлы spec/plan/tasks не привязаны к конкретному агенту исполнения, их подхватывают Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf и Qwen Code. Благодаря этому Spec Kit превратился в «организационный протокол SDD», а не в проприетарный продукт GitHub (оценка vibecoding.app, июнь 2026, score 0.816, вторичный источник).

AWS Kiro: спецификации, встроенные прямо в IDE. Выпущен в июле 2025 года, к первой половине 2026-го эволюционировал в полноценную агентную IDE. Рабочий процесс строится в три этапа: требования → проектирование → задачи. Главное отличие от Spec Kit — «хуки»: файл спецификации в Kiro может запускать заранее заданные действия агента, закладывая в пайплайн шаги, требующие внешних систем, — комплаенс, аудит, деплой. Если вам нужно заставить команду писать спецификации, выбирайте Kiro — без spec-файла он просто не запустится (официальные материалы AWS Kiro, июль 2025; документация Kiro.dev, 2026).

OpenAI Codex: AGENTS.md + композиционные Skills. В 2025–2026 годах AGENTS.md выдвинулся в центр экосистемы. Skills — ключевое расширение первой половины 2026-го: рутинные операции вроде «прочитать Excel-таблицу», «сгенерировать SQL» или «провести миграцию данных» теперь собираются заранее и вызываются как конструктор Lego. Еженедельная аудитория Codex превысила 5 миллионов пользователей к июню 2026-го, причём 20% из них — не разработчики. Это сигнал, который легко упустить: нормативное управление больше не забота только инженерных команд — это общее дело. Продуктовые менеджеры, операционные специалисты и риск-менеджеры пишут AGENTS.md (анонс OpenAI от 02.06.2026; обзор thebcms.com, 2026, оценка 0.801).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic называет проектные инструкционные документы CLAUDE.md (вышел на официальный рынок в феврале 2026 года), .claude/rules/ (правила, организованные по директориям) и Skills (общие рабочие процессы). Claude Code — самый высоко оценённый инструмент среди разработчиков в первой половине 2026 года — по данным опроса JetBrains 2026.1, показатель CSAT составил 91%, NPS — 54, и это подтверждается двумя независимыми исследованиями (Pragmatic Engineer, февраль 2026). Это самый высокий результат в индустрии AI-инструментов для программирования на данный момент (uvik.net, май 2026, оценка 0,956, сводка первоисточников). Claude Code всего за 9 месяцев вышел на годовую выручку в 2,5 миллиарда долларов (по данным раунда G Anthropic, февраль 2026), а репозиторий Skills на GitHub собрал 112 тысяч звёзд — разработчики голосуют ногами, и это лучшее доказательство реальной ценности подхода, основанного на правилах.

Alibaba Qoder: нормативный драйвер китайского рынка. Релиз состоялся в августе 2025 года, а 15 мая 2026 года продукт был обновлён до версии 1.0, официально сменив позиционирование с «AI IDE» на «Autonomous Agent Development Workbench». Ключевая особенность — Spec-Driven Workflow — была представлена в связке с Quest Mode (автономные многофайловые задачи), Expert Mode (параллельная работа экспертных команд) и RepoWiki (граф знаний репозитория). 28 мая 2026 года появились Cloud Agents (полностью управляемая среда выполнения агентов), 21 июля — Qoder Security (комплаенс-функции безопасности), а в том же месяце вышла мобильная версия (Android/iOS/HarmonyOS). К маю 2026 года глобальная аудитория превысила 5 миллионов пользователей; CLI DingTalk включил Qoder в список поддерживаемых сред выполнения агентов (Yahoo Finance 2025; Alibaba Cloud official 2026; Baidu Baike 2026.7).

Общий принцип: письменно зафиксировать «как мы работаем с ИИ» в виде документа, положить его в репозиторий и заставить всех людей и все ИИ-агенты следовать одному и тому же регламенту. У пяти платформ разная реализация (имена файлов / количество этапов / механизмы хуков), но цель абсолютно одна.

Почему это произошло массово в первой половине 2026 года? Потому что порог возможностей ИИ уже пройден: автономные агенты Claude Code, параллельные мультиагенты Codex, многофайловый рефакторинг в Cursor — ИИ больше не «инструмент автодополнения», а «коллега». Документ онбординга, который вы даёте новому сотруднику, обязан быть доступен и ИИ.

III. Управление через спецификации — это организационная способность, а не выбор инструмента

Это самый важный пункт для лиц, принимающих решения. Управление через спецификации — это не выбор инструмента, а определение того, «как наша организация взаимодействует с ИИ». Неважно, выберете ли вы GitHub Spec Kit или Claude Code; важно, зафиксировали ли вы спецификации в виде документа, положили ли в репозиторий и работаете ли по ним и люди, и ИИ.

Без этого любой самый лучший инструмент лишь позволит команде быстрее накапливать ещё больше технического долга.

Если смотреть на это в контексте масштабного развёртывания в первом полугодии 2026 года, доказательства становятся ещё убедительнее. В своём отчёте за 2026 финансовый год (июль 2026) Microsoft привела кейсы EY и Atos как образец шаблона «Frontier Firm» — не потому, что модели были новыми, а потому, что обе компании сначала ответили на вопрос «как мы будем использовать ИИ»:

EY: сначала нормативная база, потом масштабирование и результат. В 2024–2025 годах EY развернула Microsoft 365 Copilot для 150 000 сотрудников, сэкономив 2,5 миллиона часов и около 250 миллионов долларов. Ключевое условие — «сначала выстроить систему управления ИИ»: EY создала единый инструментальный контур на базе Power Platform, Copilot Studio, Azure, Foundry и Fabric, объединив нормативные требования, комплаенс и аудит в одной инфраструктуре. Именно это позволило добиться ускорения на 95%, снижения операционных затрат в финансах на 37% и сокращения до 90% ручных процессов. Вице-президент EY на AI Tour 2026 сформулировал предельно чётко: «Мы не разворачивали ИИ, а потом закрывали пробелы в управлении — мы сначала выстроили управление, а уже потом запускали ИИ».

Atos: единая плоскость управления для 19 000 агентов. Atos — одна из первых организаций в мире, развернувших Microsoft 365 E7 (Frontier Suite) и предоставивших Copilot 56 000 сотрудников в 54 странах. Одновременно у них работают 19 000 ИИ-агентов — от внутреннего ИТ и бизнес-подразделений до клиентских проектов, все создаются на базе Foundry и Copilot Studio. Ключ к успеху Atos — «единая плоскость управления»: Entra (идентификация) + Defender (безопасность) + Intune (устройства) + Purview (комплаенс) + Agent 365 (управление агентами), пять компонентов, связанных воедино. В финансовой отрасли такой подход соответствует связке «Приказ ФСТЭК № 21/239 (6 级 защиты) (аттестация защиты информационной безопасности) + оценка трансграничной передачи данных + алгоритмическое депонирование + аудит + управление моделями» — это архитектура управления, а не просто набор ИИ-инструментов.

Парадокс организационных изменений у Microsoft. В отчёте Work Trend Index за 2026 год Microsoft прямо признаёт: «организации меняются медленнее, чем отдельные сотрудники внедряют ИИ». Среди 20 000 опрошенных пользователей ИИ 82% руководителей планируют в ближайшие 12–18 месяцев расширять штат за счёт ИИ-агентов, но лишь 24% уже завершили внедрение на корпоративном уровне. 81% руководителей ожидают, что ИИ-агенты будут в значительной или умеренной степени интегрированы в их ИИ-стратегию — и снова только 24% уже это сделали. Иными словами, большинство компаний находятся на дистанции в 12–18 месяцев между «готовимся» и «сделали». И главный инструмент, который поможет сократить этот разрыв, — нормативное регулирование и стандарты.

Источники: Microsoft FY26 retrospective, 28.07.2026; Microsoft 2026 Work Trend Index Annual Report, 05.05.2026 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, первоисточник в формате PDF); анализ Futurum Group от 26.01.2026 (вторичный источник).

Вывод первый: инвестиции в нормативное регулирование — это высокая окупаемость.

Данные CodeRabbit дают чёткую основу для расчёта ROI: частота проблем в коде, создаваемом ИИ, примерно в 1,7 раза выше, а количество уязвимостей безопасности снижается в 2,74 раза. Что это означает на практике:

  • Меньше переделок (в финансовой отрасли одна повторная проверка на соответствие требованиям — это 2–4 недели работы)
  • Меньше инцидентов безопасности (штрафы регулятора и репутационный ущерб от одной утечки данных)
  • Ниже затраты на сопровождение (сокращение технического долга на 40% — вполне типичная цифра)

Написать файл проектных стандартов CLAUDE.md/AGENTS.md — это, пожалуй, самое выгодное инженерное действие в эпоху ИИ. Кейс EY даёт наглядную иллюстрацию в реальных деньгах: 150 тысяч сотрудников с Copilot — экономия 250 миллионов долларов. Обратите внимание: EY сэкономил не потому, что «инструмент оказался мощным», а потому, что «стандарты позволили этому инструменту раскрыть свою ценность».

Вывод второй: закрепляйте стандарты в процессах организации, а не в головах отдельных людей.

Если стандарты живут только в голове у опытного инженера — они исчезнут, как только этот человек сменит работу. Их нужно фиксировать в:

  • Документации репозитория (AGENTS.md / CLAUDE.md / constitution.md)
  • CI-гейтах (автоматическая проверка соблюдения стандартов)
  • Общих конфигурациях команды (система Skills, чтобы вся команда могла ими пользоваться)

Пусть стандарты станут активом организации, а не личным навыком. Это особенно важно в финансовой отрасли — ваши требования комплаенса, правила безопасности, бизнес-правила — это активы уровня организации, а не «опыт» отдельного инженера. 19 000 агентов Atos работают в 54 странах именно потому, что управление здесь — это не «кто-то разбирается», а «система принуждает».

Вывод третий: шлюзы важнее скорости.

Пятиэтапные шлюзы GitHub Spec Kit (constitution → specify → plan → tasks → implement), правило Claude Code «не пиши код, пока тесты не падают», требование Kiro «без spec не запустишь» — всё это делает одно и то же: ставит «тормоз» между ИИ и конечным результатом. На каждом шаге есть проверяемый артефакт (spec.md, plan.md, tasks.md), который можно отклонить или изменить до генерации кода.

Чем автономнее ИИ, тем больше ему нужны шлюзы. Change Advisory Board (Change Advisory Board (CAB)) в финансовой отрасли, процедуры алгоритмического регулирования, оценка уровня защищённости — всё это по сути шлюзы перед запуском в производство. ИИ-коду нужны аналогичные шлюзы, просто в другой форме. Те 62% команд из отчёта New Relic 2026, которые «уверенно выкатывают без ревью», расплачиваются за эту уверенность повышенной аварийностью (78%).

Три этапа внедрения стандартов в финансовой отрасли (практика H1 2026) Этап 1: инвентаризация правил 2–4 недели | самый трудоёмкий, максимальный ROI Чек-лист требований комплаенса (защита/выезд/регистрация) Правила безопасности (пароли/шифрование/логи) Бизнес-правила (риск-контроль/транзакции/биллинг) Технические ограничения (старые API/версионные лимиты) Управление поставщиками (контракты/аудит/ответственность) Собрать разрозненные правила Структурировать в документацию Этап 2: внедрение в репозиторий 1-2 недели | в репозиторий, AI автозагрузка CLAUDE.md / AGENTS.md constitution.md Определение Skills (общие рабочие процессы) Проектирование гейткипинга (пять этапов) .claude/rules/ (иерархические правила) Поместить правила в репозиторий, AI автозагрузка Этап 3: институционализация Постоянно | от инструмента к организационной способности CI-гейткипинг (автопроверка) Общая конфигурация команды (Skills) Регулярное обновление (квартальный обзор) Метрики (доля дефектов/процент соответствия) Управление агентами (Agent 365 уровень 1) Стандарты становятся активом организации, Не зависят от отдельных лиц

Первый этап самый затратный по времени, но ROI самый высокий
Правила большинства финансовых организаций разбросаны по документам/почте/мозгам, первая систематизация — 3-8 недель вложений

Четыре. Реальные этапы внедрения в первом полугодии 2026 года

Ниже — трёхэтапный путь на примере финансовой отрасли. Остальные строго регулируемые сектора могут использовать его как ориентир. Практика EY и Atos в первом полугодии 2026 года как раз соответствует этим трём этапам.

Этап первый: инвентаризация правил (2–4 недели).

Самый трудоёмкий, но при этом самый рентабельный этап. Нужно собрать все правила, разбросанные по разным системам и документам:

  • Требования комплаенса: для финансовой отрасли минимальный базовый уровень = защита ИСПДн уровня 3 + оценка трансграничной передачи данных + регистрация алгоритмов (если не хватает хотя бы одного — ИИ разворачивать нельзя). Дальше — требования к регуляторной отчётности, защита данных клиентов, ограничения на трансграничные потоки данных, а также то, какие данные вообще можно показывать ИИ.
  • Правила безопасности: управление паролями, стандарты шифрования, обработка чувствительных полей, требования к журналированию.
  • Бизнес-правила: пороги риск-аппетита, условия выплат, лимиты по операциям, логика тарификации.
  • Технические ограничения: интерфейсы унаследованных систем, нейминг в базах данных, ограничения версий фреймворков.
  • Управление поставщиками: как прописать в договоре требование, чтобы вендор следовал нашим стандартам, и как проводить аудит использования ИИ у поставщика.

Типичный сценарий: на этапе инвентаризации одна securities-компания обнаружила, что правила разбросаны по множеству Word-документов, JIRA-вики, личным письмам и Excel-таблицам — только после наведения порядка получился структурированный перечень правил. Подход Atos более системный — они сразу разбили правила на пять категорий: «комплаенс, безопасность, бизнес, технологии, поставщики», для каждой завели отдельный governance-процесс и подключили всё к единой управляющей плоскости Agent 365.

Это не техническая задача, а организационная — нужно собрать вместе комплаенс, безопасность и бизнес-подразделения и зафиксировать правила, с которыми согласны все. При первом проходе финансовой организации обычно требуется от 3 до 8 недель — но это постоянный организационный актив.

Этап второй: загрузка в репозиторий (1–2 недели).

Правила, собранные на первом этапе, оформляются в документы и помещаются в репозиторий. GitHub Spec Kit использует constitution.md, Claude Code — CLAUDE.md, OpenAI Codex — AGENTS.md, Alibaba Qoder — Spec Workflow. Имена файлов разные, цель одна — чтобы AI подхватывал их в момент открытия репозитория.

Структура предложения (основной формат на H1 2026):

  • Обзор проекта: что делает система и кому она предназначена
  • Некомpromиссные принципы: красные линии безопасности, комплаенса и бизнеса
  • Технологический стек и ограничения: какие фреймворки, базы данных и стандарты интерфейсов используются
  • Стандарты кодирования: соглашения об именовании, структура каталогов, минимальные требования к покрытию тестами (без принудительного ритма TDD — достаточно четко прописать процент покрытия, обязательные сценарии и запрещенные пути; TDD — это организационный выбор, а не жесткое требование стандарта)
  • Бизнес-правила: логика риск-контроля, правила транзакций, правила биллинга
  • Требования комплаенса: защита информации, трансграничная передача данных, регуляторная отчетность, необходимость регистрации алгоритмов ИИ
  • Правила использования ИИ: в каких сценариях ИИ допустим, где обязательна ручная проверка, правила трансграничной передачи данных
  • Управление поставщиками: условия контрактов, механизмы аудита, распределение ответственности

Приложение: каркас CLAUDE.md для финансового сектора (~200 строк, можно форкнуть и адаптировать)

Ниже представлен каркас CLAUDE.md для модернизации ядра системы акционерного коммерческого банка, организованный по принципу «некомpromиссные принципы → требования комплаенса → правила использования ИИ → бизнес-правила → инженерные ограничения». Вам не нужно начинать с нуля — достаточно заполнить пустые поля своими конкретными правилами.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
# CLAUDE.md — <имя системы> — правила взаимодействия с ИИ

> Область применения: <имя системы> v<версия>; все ИИ-агенты (Claude Code / Cursor / Copilot / Codex),
> работающие в данном репозитории, обязаны соблюдать настоящую спецификацию. Документ поддерживается
> <комитет по управлению> и пересматривается ежеквартально.
> Последнее обновление: YYYY-MM-DD

## 1. Обзор проекта
- **Бизнес-позиционирование**: имя ключевой системы / обслуживаемые сегменты клиентов / основные типы транзакций
- **Критическая цепочка**: транзакция → контроль рисков → клиринг → сверка → отчётность
- **Окно недоступности**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (любые изменения запрещены)
- **Ключевые зависимости**: вышестоящая <система>, нижестоящая <система>, платформа регуляторной отчётности

## 2. Не подлежащие обсуждению принципы (красные линии — нарушение = отказ в слиянии)

### 2.1 Красные линии безопасности
- Пароли, ключи и токены — только через KMS (Key Management Service); **жёсткое кодирование запрещено**, **вывод в журналы запрещён**
- Чувствительные поля клиента (удостоверение личности / номер карты / CVV / номер телефона) **должны храниться в зашифрованном виде**; открытый текст в базе запрещён
- В журналах запрещено появление: полного удостоверения личности, полного номера карты, пароля в открытом виде, комбинации «имя клиента + номер телефона»
- Вызовы внешних API должны проходить через API-шлюз; прямое подключение запрещено

### 2.2 Красные линии соответствия
- Код, сгенерированный ИИ и предусматривающий доступ к данным клиентов, должен содержать в описании PR пометку «доступ к данным: <поле>»
- Трансграничная передача данных запрещена; **любая передача данных за рубеж должна проходить через оценку трансграничной передачи данных** (обращаться в комплаенс)
- Алгоритмические решения (кредитование / страховые тарифы / антифрод) должны сохранять возможность ручной проверки
- Любое изменение модели требует регистрации алгоритмов; номер регистрации должен быть указан в описании PR

### 2.3 Красные линии бизнеса
- Изменение порогов контроля рисков требует двойной подписи руководителя по рискам и бизнес-руководителя
- Операции с клиентскими средствами должны иметь идемпотентность + откат при сбое
- Лимиты транзакций, тарифы и параметры продуктов управляются через платформу управления параметрами; жёсткое кодирование в коде запрещено

## 3. Технологический стек и ограничения
- **Языки**: Java 17 (ядро) / Kotlin (новые модули) / SQL (база данных)
- **Фреймворк**: Spring Boot 3.x + Spring Cloud Alibaba
- **База данных**: OceanBase 4.x (режим совместимости с MySQL); **внешние ключи запрещены**
- **Спецификации интерфейсов**: внутри — только gRPC; внешние — OpenAPI 3.0; RESTful только для административных интерфейсов
- **Соглашения об именовании**: классы Java в PascalCase, методы в camelCase, константы в UPPER_SNAKE; таблицы `t_<домен>_<сущность>`; индексы `idx_<таблица>_<поле>_<порядок>`
- **Структура пакетов**: `com.<компания>.<домен>.<поддомен>.<слой>` (например, `com.bank.pay.tx.core.service`)

## 4. Стандарты кода
- **Минимальное покрытие тестами**: критическая цепочка ≥ 80 %, утилиты ≥ 60 %; любой новый код, поставляемый в PR, должен сопровождаться тестами
- **Обязательные пути тестирования**: все контроллеры должны иметь интеграционные тесты (включая пути сбоев); все ветви enum должны иметь модульные тесты
- **Запретные пути**: запрещено изменять каталог `<модули исторического наследия>` — сначала создайте слой адаптера
- **Управление зависимостями**: добавление сторонней зависимости требует SCA-сканирования + одобрения безопасности

## 5. Бизнес-правила (по доменам)
### 5.1 Транзакции
- Лимит на одну операцию: <сумма>; лимит в сутки: <сумма>; превышение лимита — ручное утверждение
- Временное окно транзакций: <HH:MM> ~ <HH:MM>
- Определение дубликата: в пределах <временного окна> совпадение по <полю> считается дубликатом

### 5.2 Контроль рисков
- Приоритет сопоставления чёрных списков: внутренний чёрный список → нисходящий регуляторный список → судебная заморозка
- Порог срабатывания антифрод-модели: <оценка>; при превышении — обязательная ручная повторная проверка

### 5.3 Тарификация
- Изменение тарифа должно сопровождаться номером версии + датой вступления в силу
- Исторические заказы рассчитываются по тарифу, действовавшему на дату вступления в силу; обратной силы нет

## 6. Требования соответствия
- MLPS уровень 3: <организация оценки>, <дата следующей оценки>
- Оценка трансграничной передачи данных: область применения (только модули трансграничной деятельности)
- Регистрация алгоритмов: область применения (кредитование / страховые тарифы и иные ключевые алгоритмы), номер регистрации `<номер регистрации>`
- Регуляторная отчётность: таблица соответствия полей CBIRC / Народный банк Китая находится по пути `<путь>`

## 7. Стандарты использования ИИ
- **Допустимые сценарии ИИ**: шаблонный CRUD, генерация модульных тестов, черновики документации, предложения по оптимизации SQL
- **Сценарии обязательной ручной проверки**: логика контроля рисков, правила тарификации, управление правами, шифрование/дешифрование, трансграничные данные
- **Сценарии, в которых ИИ не может действовать автономно**: материалы Change Advisory Board (CAB) (Change Advisory Board) на утверждение, выполнение изменений в продуктивной среде, реагирование на инциденты
- **Правила трансграничной передачи данных**: обучающие данные / промпты / журналы вывода не должны покидать периметр; приоритет у локально развёрнутых версий (<поставщик>)
- **Требования к аудиту**: весь код, сгенерированный ИИ, должен содержать в описании PR пометку «ИИ-ассистент: <имя инструмента>»

## 8. Управление поставщиками
- **Допуск поставщиков**: обязательно предоставление отчёта SOC 2 / ISO 27001; модели ИИ должны сопровождаться model card
- **Контрактные условия**: принадлежность данных, объяснимость модели, условия выхода, право на аудит
- **Механизм аудита**: ежеквартальный аудит использования ИИ поставщиками; для поставщиков высокого риска — ежемесячный

## 9. Управление и обновления
- **Владелец**: <комитет по управлению> (комплаенс + безопасность + архитектура + бизнес)
- **Частота обновлений**: ежеквартальный пересмотр; экстренные изменения идут по ускоренной процедуре (двойная подпись + публикация за 24 ч)
- **Журнал изменений**: см. `CLAUDE_CHANGELOG.md`
- **Обработка нарушений**: первое нарушение = предупреждение + принудительное обучение; второе = приостановка доступа к инструментам ИИ; третье = отзыв прав

## 9. 治理与更新
- **所有者**：<治理委员会>（合规 + 安全 + 架构 + 业务）
- **更新频率**：季度评审；紧急变更走快速通道（双签 + 24h 公示）
- **变更日志**：见 `CLAUDE_CHANGELOG.md`
- **违规处理**：首次违规 = 警告 + 强制培训；二次违规 = 暂停 AI 工具使用；三次 = 取消权限

Этот скелет — не «эталонный ответ», а «шаблон для заполнения». Что именно вы впишете в каждую ячейку, важнее, чем объём текста: пустые места показывают, о чём ваша компания «ещё не подумала».

Типичный пример: в одном акционерном банке CLAUDE.md содержит отдельное правило обработки паролей — если ИИ генерирует код, связанный с паролями, он обязан вызывать внутренний API управления ключами; хардкод запрещён. Такие правила составляют значительную долю причин возврата кода на доработку по итогам комплаенс-проверки.

Важное нововведение первой половины 2026 года — Skills / определение рабочих процессов: это уже не просто документация, а инструментальная цепочка, которую ИИ может вызывать. Система Skills в Claude Code (в феврале 2026 года появилась в официальном маркетплейсе Anthropic, 112 000 звёзд на GitHub) превращает такие операции, как «прочитать Excel-таблицу», «сгенерировать SQL» или «провести миграцию данных», в переиспользуемые рабочие процессы. Это ключевая эволюция нормативного подхода в первой половине 2026 года: нормы — это не только ограничения, но и исполняемые рабочие процессы.

Третий этап: институционализация (постоянно).

Написать спецификацию — не финал, а отправная точка. Дальше её нужно встроить в организационные процессы:

  • CI-гейты: автоматическая проверка кода на соответствие спецификации (например, детекция хардкода паролей, незашифрованных чувствительных полей)
  • Общие конфиги для команды: через систему Skills вся команда работает по единому стандарту
  • Регулярное обновление: правила меняются — спецификация должна меняться вместе с ними (квартальный ревью)
  • Метрики и обратная связь: отслеживание доли дефектов в AI-коде, прохождения compliance-проверок, доли переделок
  • Губернаторство агентов: расширение практик управления с людей на AI-агентов — Atos на Agent 365 сделали это системным, а не индивидуальным уровнем

EY и Atos в первой половине 2026 года оба превратили третий этап в «организационную способность». Экономия EY в 2,5 млн часов — результат правильно выстроенных первого и третьего этапов: второй лишь перевёл правила в формат, читаемый AI.

Пять. Вариант для строгого регулирования: три инженерных подхода к встраиванию комплаенса

В сильно регулируемых отраслях — финансы, телеком, медицина — внедрение спецификаций проходит дополнительную проверку: комплаенс — не внешняя надстройка, а встроенный код. Ниже — три подхода к встраиванию комплаенса, подтверждённые в первой половине 2026 года. CIO и руководители цифровой трансформации могут использовать их как готовую основу при проектировании организации.

5.1 Встраивание представителя комплаенса в стрим-команду: когда соответствие требованиям «присутствует», а не «согласовывается»

Традиционный подход: команда разработчиков пишет код, служба комплаенса проверяет задним числом. К моменту обнаружения проблемы код уже две недели как в проде, а на переделку уходит от двух до четырёх недель. Суть проблемы в том, что комплаенс подключён на самом конце процесса.

Новый подход: в каждую стрим-команду (stream-aligned team) встраивается представитель комплаенса — по принципу двойного подчинения: «сплошная» линия — в отдел комплаенса, «пунктирная» — в бизнес-команду. Как это выглядит на практике:

  • Штатная единица: один представитель комплаенса на 6–8 стрим-команд. Он числится в отделе комплаенса, но физически сидит вместе с бизнес-командой — это не «командировка» и не временное прикомандирование
  • KPI по «пунктирной» линии: 50% оценки представителя комплаенса завязано на «долю дефектов комплаенса» и «процент прохождения проверок с первого раза» в бизнес-команде, а не только на «покрытие аудитом» со стороны комплаенса
  • Включение на раннем этапе: представитель комплаенса участвует в ежедневных стендапах (достаточно раз в неделю), в ревью пул-реквестов, а код, сгенерированный ИИ, обязан пройти через него до слияния в основную ветку — а не постфактум, когда нарушение уже обнаружили
  • Инструментальная поддержка: представитель комплаенса работает через Skills с чек-листами проверок, а не сверяет требования вручную, пункт за пунктом

Типичный сценарий: один из национальных акционерных банков в первом полугодии 2026 года запустил пилотный проект — три стрим-команды с встроенными compliance-представителями, и доля отклонённого AI-кода по причинам несоответствия требованиям снизилась с 35% до 8%. Ключевой фактор — не в том, что compliance стал «строже смотреть», а в том, что он стал «смотреть раньше». Решающее условие здесь — чтобы пунктирная мотивация compliance-представителей была привязана к бизнес-целям — если KPI compliance-представителя по-прежнему определяется только задачами compliance-отдела, встраивание обречено на провал.

5.2 Compliance как enabling team: превращаем ограничения в affordance

Традиционный подход: compliance-команда играет роль «привратника», а бизнес-команды воспринимают её как «источник проблем». В итоге — игра с нулевой суммой.

Новый подход: compliance-команда перестраивается по модели enabling team из Team Topologies — она не пишет код напрямую и не ревьюит PR, но даёт бизнес-командам три вещи, которые позволяют им «соблюдать требования самостоятельно»:

  1. Проверки соответствия в конвейере CI: Частые точки комплаенса — жёстко закодированные пароли, открытые чувствительные поля, трансграничная передача данных, точки принятия алгоритмических решений — превращаются в обязательные шлюзы в GitHub Actions / GitLab CI. Pull Request от бизнес-команды автоматически запускает проверку, и при несоответствии — сразу fail, без ручного прогона со стороны комплаенс-представителя.
  2. Регуляторные требования как affordance (средовые ограничения): Например, при разработке функций, работающих с данными клиентов, плагин в IDE подсказывает: «Для этого поля рекомендуется вызов KMS»; при записи логов автоматически обнаруживается наличие чувствительной информации и выдаётся предупреждение. Комплаенс становится «естественным действием в процессе разработки», а не «уведомлением о нарушении перед релизом».
  3. Общая библиотека Skills + обучение комплаенсу: Комплаенс-команда поддерживает набор «комплаенс-Skills», который вызывается при онбординге новых сотрудников / переходе между командами — комплаенс-знания превращаются из «документации» в «исполняемый инструмент».

Типичный сценарий: региональный банк во втором полугодии 2026 года внедрил комплаенс-гейты в CI и подсказки в IDE, сократив среднее время на проверку AI-кода на соответствие с 45 минут до 8 минут на одну проверку. Суть не в том, что «проверка стала быстрее», а в том, что AI «не допускает ошибок» уже на этапе генерации.

5.3 Двухскоростной комплаенс: соответствие темпу бизнеса

Последняя деталь: комплаенс не должен быть «под одну гребёнку». Разделите правила на два уровня риска:

  • Правила высокого риска (связаны с клиентскими средствами / алгоритмическими решениями / трансграничной передачей данных / критическими требованиями безопасности) — строгий контроль: обязательная ручная проверка + повторное подтверждение ИИ + регистрация в Change Advisory Board (Change Advisory Board (CAB))
  • Правила низкого риска (типовой CRUD-код / утилиты / генерация документации) — самообслуживание: достаточно автоматической проверки в CI, ручная проверка не требуется

Контрольная плоскость Agent 365 от Atos по сути и есть такое разделение — агенты разных уровней привязаны к разным требованиям управления. Когда правила комплаенса распределены по уровню риска, бизнес-команды чувствуют: «комплаенс — это не сплошные блокеры на каждом шагу».

Общий вывод по этим трём пунктам: встраивание комплаенса — это не добавление ещё одного процесса, а перепроектирование структуры и стимулов команды. Если ваш комплаенс-отдел всё ещё работает в режиме «постфактум-проверок», внедрение нормативно-управляемой разработки упрётся в самый сложный этап — «институционализацию». Комплаенс-отделу сначала нужно трансформироваться самому, тогда нормативно-управляемая разработка в бизнес-командах пойдёт гладко.

Шесть. Возможные вопросы

«У нас уже есть стандарты кодирования. Чем это отличается?»

Стандарты кодирования отвечают на вопрос «как писать код», а нормативно-управляемая разработка — на вопрос «как работать с ИИ». Стандарты кодирования не покрывают: бизнес-правила, требования комплаенса, политику использования ИИ. Нормативно-управляемая разработка — это эксплицитное описание всего процесса совместной работы человека и ИИ, а не руководство по стилю кода.

«Не замедлит ли написание спецификаций разработку?»

В краткосрочной перспективе — да, в долгосрочной — нет. Данные CodeRabbit дают однозначный ответ: дефекты в коде, написанном ИИ без ограничений, встречаются примерно в 1,7 раза чаще, а уязвимости — в 2,74 раза чаще. В финансовой отрасли одна итерация доработок по итогам комплаенс-проверки обходится в 2–4 недели — и одной предотвращённой такой итерации хватит, чтобы целый месяц писать спецификации. Экономия в 250 миллионов долларов у EY — это реальное доказательство того, что превращение этого процесса в организационную компетенцию работает.

«А если в нашей команде никто не умеет писать спецификации?»

Начинать с нуля не нужно. В GitHub Spec Kit, Claude Code Superpowers и AWS Kiro уже есть готовые шаблоны. Вам остаётся только добавить правила, специфичные для вашей организации — в основном это требования комплаенса и безопасности, которые ваши отделы комплаенса и ИБ давно сформулировали, просто не положили туда, где их мог бы увидеть ИИ.

«Инструментов ИИ так много — какой выбрать?»

Неважно. Беріть те, що вже використовуєте. Специфікації не прив’язані до інструментів — CLAUDE.md працює в Claude Code, Cursor і Codex; AGENTS.md працює в екосистемі OpenAI; constitution.md взагалі не залежить від моделі. Головне — писати специфікації, а не міняти інструменти. EY розгортає все в екосистемі Microsoft, Atos — теж у Microsoft. Різниця у виборі інструментів — лише зовнішня; уніфікована архітектура управління — ось що справді має значення.

«У серпні 2026 року EU AI Act набуде повної чинності. Чи це нас стосується?»

Да. EU AI Act вступает в полную силу 2 августа 2026 года и предъявляет обязательные требования к системам ИИ высокого риска — включая кредитование, страхование, отбор кандидатов на работу и критическую инфраструктуру. Речь идёт об управлении рисками (ст. 9), качестве данных (ст. 10), прозрачности документации (ст. 11–13), контроле со стороны человека (ст. 14) и точности/устойчивости системы (ст. 15). Штрафы достигают 35 млн евро или 7% глобальной выручки. Для китайских компаний, выходящих на европейский рынок, это обязательный экзамен. Но даже если вы работаете только внутри Китая, обойти EU AI Act не получится: это самый цитируемый регуляторный стандарт в мире, и его требования косвенно влияют на вас через поставщиков, партнёров и трансграничные операции (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

А что у нас? Китайский подход: регулируем не ИИ, а его применение

В Китае генеративный ИИ регулируется через три инструмента: регистрация алгоритмов, проверка обучающих данных и оценка безопасности. Ключевой документ — «Временные меры по управлению генеративными сервисами ИИ», вступившие в силу в августе 2023 года. Главное различие между китайской и европейской системами — не в деталях, а в философии регулирования.

АспектEU AI ActКитайские «Меры по управлению генеративными ИИ-сервисами»
Правовой статусГоризонтальный регламент (распространяется на все ИИ-системы)Вертикальные правила (фокус на генеративные ИИ-сервисы)
Классификация рисков4 уровня (неприемлемый / высокий / ограниченный / минимальный)2 уровня (затрагивающие общественную безопасность / общегражданское применение)
Момент регулированияПредварительный (регистрация ещё на этапе разработки)Последующий (регистрация после запуска + регистрация алгоритма)
ПрозрачностьВысокая (требуется публикация сводки об источниках обучающих данных, model card)Средняя (требуется соответствие данных требованиям, но раскрытие источников необязательно)
Верхний предел штрафов7% глобальной выручки или 35 млн евроПриостановка сервиса / штраф (обычно кратно сумме незаконного дохода)
Сфера примененияВсе компании, превышающие порог глобальной выручкиВсе субъекты, предоставляющие услуги на территории Китая

На практике ИИ-системы финансовых организаций в Китае обычно одновременно регулируются тремя наборами правил — «Мерами по управлению генеративным ИИ» (базовый уровень) + «Мерами по управлению интернет-кредитованием коммерческих банков» (бизнес-уровень) + системой защиты информационной безопасности (等保, děngbǎo — китайский аналог ISO 27001) + алгоритмической регистрацией (уровень соответствия). Это означает, что при построении нормативной базы внутри страны нельзя механически копировать框架 EU AI Act — нужно заложить в CLAUDE.md все три китайские линии: «соответствие обучающих данных + регистрация алгоритмов + регуляторная отчётность».

Для компаний, выходящих на зарубежные рынки: четыре компонента EU AI Act — «управление рисками + управление данными + прозрачность документации + контроль со стороны человека» — это то направление, к которому постепенно движется и китайское регулирование. Уже в 2025 году несколько ответов на заявки по регистрации генеративного ИИ от Управления киберпространства Китая (CAC) заметно заимствовали гранулярность европейского подхода. Если сегодня писать нормативы, совместимые с EU AI Act, то с высокой вероятностью они будут совместимы и с ужесточением китайского регулирования в ближайшие 3 года (объявления CAC о регистрации 2025–2026; eu-ai-act compliance 2026.6).

7. Выводы для лиц, принимающих решения

Вывод первый: написать проектный регламент в виде CLAUDE.md/AGENTS.md — это инженерное действие с самой высокой окупаемостью в эпоху ИИ.

Вывод 2: Управляемость через стандарты — это организационная компетенция, а не выбор инструмента.

GitHub Spec Kit или Claude Code — не имеет значения. Важно, определили ли вы, как ваша организация взаимодействует с ИИ. Без этого даже лучший инструмент лишь позволит команде быстрее накапливать технический долг.

Вывод 3: Закладывайте стандарты в организационные процессы, а не полагайтесь на отдельных людей.

Если стандарты существуют только в голове одного опытного инженера, они будут утеряны при смене кадров. Их необходимо фиксировать в документации репозитория, CI-гейтах, общих конфигурациях команды и платформах управления агентами. Стандарты должны стать организационным активом, а не личным навыком. 19 000 агентов Atos работают в 54 странах именно потому, что управляемость — это не «кто-то разбирается», а «система принуждает».

Вывод 4: Гейты важнее скорости.

Пятиэтапные шлюзы GitHub Spec Kit, принцип Superpowers «не пиши код, пока тесты не упадут», требование Kiro «без spec не запустишь» — всё это про одно: поставить «тормоз» между ИИ и конечным результатом. Чем мощнее ИИ, тем раньше нужно включать управление. Те самые 78% инцидентов из отчёта New Relic 2026 — это цена того, что 62% команд «выкатывают без ревью». CIO из финансового сектора понимают это лучше всех: ваш Change Advisory Board, процедуры алгоритмического регулирования, аттестация по 6-уровневой системе защиты ФСТЭК (Приказ № 21/239) — всё это гейты перед продакшеном. Для ИИ-кода нужны такие же гейты, и они должны стоять ещё раньше.

Самопроверка на честность (не приукрашивайте): ваш комплаенс-ревью ИИ-кода часто уходит в доработку? Что в последний раз сломал код, сгенерированный ИИ? Если спросить технического руководителя «как мы работаем с ИИ» — он покажет документ? Если хоть на один вопрос нет ответа — значит, нормативная база у вас ещё не внедрена. Сначала — стандарты, потом — инструменты.

Три вопроса для руководителя

Напоследок — три вопроса. Не чек-лист, а готовая основа для разговора с командой:

  1. “Якщо завтра всі інструменти ШІ зникнуть, насколько сильно снизится качество кода в вашей команде?” — этот вопрос вскрывает реальную ценность норм и стандартов: если ответ “значительно снизится”, значит, ваши регламенты ещё не устоялись; если ответ “почти не изменится” — вы уже на пути к управляемому через стандарты процессу.
  2. “В вашем проекте по внедрению норм и стандартов для ИИ-разработки — отдел комплаенс играет роль ‘контролёра’ или ‘помощника’ (enabler)?” — если ответ “контролёра”, ваша скорость упрётся в бюрократические барьеры на этапе согласований; если “помощника” — вы уже идёте по пути, описанному в разделе 5.2.
  3. “Через 12–18 месяцев как изменится размер вашей команды?” — согласно Microsoft WTI 2026, 82% руководителей планируют «расширять» штат за счёт ИИ-агентов. Если ваш ответ “никак”, то либо бизнес не растёт, либо ваша организационная структура не поспевает за выгодами от внедрения норм и стандартов.

Правильных ответов на эти три вопроса не существует. Но направление вашего ответа важнее, чем сам ответ.

Что дальше

Это шестая статья из цикла о трансформации разработки ПО в эпоху ИИ. Мы прошли путь от закона Конвея (структура организации определяет архитектуру) через Team Topologies (как проектировать саму организацию) к смещению узкого места (оно теперь в верификации, а не в написании кода). Сегодня мы говорим о том, как с помощью документации и стандартов направлять поведение ИИ-инструментов.

В седьмой части мы рассмотрим инфраструктуру, на которой всё это держится, — протокол MCP (Model Context Protocol). Почему открытый протокол от Anthropic называют «USB-C для ИИ», почему OpenAI, Google и Microsoft все последовали за ним, и как он делает возможной совместимость множества инструментов и мультиагентных систем.

Хотите внедрить этот подход в своей компании?

Когда нормативно-ориентированный подход приходит в организацию, на практике обычно всплывают несколько конкретных вопросов: как зафиксировать ключевые правила в CLAUDE.md / AGENTS.md, как привести существующий код в соответствие с нормами, как встроить комплаенс и по каким метрикам оценивать пилотный проект.

Сейчас доступны три формата сотрудничества:

  • Корпоративное обучение: на материале ваших реальных проектов — отработка структуры нормативных документов, проектирование CI-гейтов, маршрут внедрения комплаенса и построение механизмов управления.
  • Экспертный консалтинг: сфокусированная проработка одного конкретного решения, например «стоит ли нам начинать с CLAUDE.md / AGENTS.md» или приоритизация мероприятий по приведению унаследованного кода в соответствие с нормами.
  • Выступления для руководства и отраслевые доклады: темы — ИИ-инструменты программирования, нормативно-ориентированный подход, организационное управление и Frontier Firms.

Статья предлагает универсальную рамочную модель. Однако практическое внедрение всегда требует переосмысления с учётом комплаенс-требований конкретной компании, регуляторных границ, инженерной зрелости и существующих процессов поставки. По вопросам сотрудничества — coach@iaiuse.com.

Дополнительно: «Методология „Витрина“ v1.0» (Медленно учимся AI, выпуск 187) — системное описание 7-шагового фреймворка для ИИ-трансформации предприятий.

О серии

«Трансформация разработки ПО в эпоху ИИ» — исследовательская серия для CIO, CDO, CTO и руководителей цифровой трансформации в телекоме, финансах, производстве и электронной коммерции. Всего 18 статей, посвящённых тому, как ИИ-инструменты разработки, нормативно-ориентированные практики и организационное управление влияют на процессы поставки ПО, оргструктуру и инженерную зрелость.

Серия опирается на академические статьи, материалы вендоров и отраслевые отчёты — исследовательская база насчитывает более 200 источников. Ключевые тезисы сопровождаются указанием уровня доказательности: мы различаем подтверждённые факты, заявления вендоров, отраслевые наблюдения и авторские гипотезы.

У меня почти 8 лет опыта в консалтинге и бизнес-анализе для крупных предприятий, включая работу в IBM над проектами в телекоме, финансах, страховании и производстве. Затем я продолжил работать на передовой — в разработке операторских и интернет-продуктов, а также ИИ-приложений, занимаясь анализом требований, продуктовым дизайном и кросс-функциональным внедрением.

Этот цикл материалов о нормативно-ориентированном подходе, организационном управлении и инженерной практике основан на реальном опыте внедрений, а также на открытых исследованиях и отраслевых кейсах, прошедших перекрёстную проверку. Всё, что касается конкретных проектов, деидентифицировано; часть отраслевых сценариев представляет собой типовые разборы ситуаций — соответствующие источники указаны в конце материала.

За этим блогом стоит небольшая команда — я и 1–2 коллеги, с которыми мы давно работаем вместе. Мы разделяем направления: исследование AI-инструментов для разработки, разбор кейсов по организационному управлению и коучинговые диалоги. Большинство проектов, о которых мы пишем как о «пройденных вместе с компаниями», — это совместная работа нашей команды. Мы по-прежнему не называем клиентов и не раскрываем имена — анонимность сохраняется и оставляет пространство для будущих коллег по совместной работе.

Источники (все проверены, по каждому указан уровень доказательности)

  • CodeRabbit (2025.12). State of AI vs Human Code Generation Report. Проблемы в AI-коде встречаются в 1,7 раза чаще, чем в коде, написанном человеком (10,83 против 6,45 проблемы на PR), логика/корректность — в 1,75 раза, качество кода — в 1,64 раза, безопасность — в 1,57 раза, обработка паролей — в 1,88 раза, XSS — в 2,74 раза. Уровень доказательности: первый. Источник: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263

  • The Register (2025.12.17). Репортаж о полном отчете CodeRabbit: анализ 470 открытых PR, PR с участием AI содержат 10,83 проблемы против 6,45 у чисто ручных. Уровень доказательности: второй. Источник: тот же URL

  • CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap” — 2026 год станет переломным: фокус сместится со «скорости генерации кода» на «качество кода и управление». Уровень доказательности: второй. Источник: https://tfir.io/ai-code-quality-2026-guardrails

  • New Relic (2026). The 2026 State of AI Coding Report. 78% команд сообщают о росте числа инцидентов после внедрения AI-кода; 62% технических руководителей признают, что их команды «уверенно выкатывают код без ревью»; 96% считают наблюдаемость обязательным условием. Уровень доказательности: первый (отчёт вендора). Источник: https://newrelic.com/resources/report/2026-state-of-ai-coding

  • Microsoft 2026 Work Trend Index Annual Report (2026.5.5). Опрос 20 000 работников, использующих ИИ, в 10 странах; 82% руководителей планируют в течение 12–18 месяцев расширять штат за счёт ИИ-агентов; 81% ожидают умеренной или значительной интеграции ИИ-агентов; 24% уже внедрили их на корпоративном уровне; 49% диалогов с Copilot поддерживают когнитивную работу; 58% пользователей ИИ совершают «то, что было невозможно год назад», а среди Frontier Professionals этот показатель достигает 80%. Уровень доказательности: первый. Источник: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf

  • Обзор FY26 Microsoft: от экспериментов с ИИ к трансформации на переднем крае (28.07.2026). EY развернула Microsoft 365 Copilot для 150 000 сотрудников, что позволило сэкономить 2,5 млн часов и около 250 млн долларов; масштабирование на 400 000 сотрудников по всему миру дало ускорение на 95%, снижение затрат на финансовые операции на 37% и сокращение до 90% ручных рабочих процессов. Atos внедрила Copilot для 56 000 сотрудников в 56 странах, добавив 19 000 ИИ-агентов, с единой плоскостью управления для идентификации, безопасности, соответствия и управления. Уровень доказательности: первый (официальный обзор Microsoft). Источник: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Стратегическое партнёрство Atos Group и Microsoft (09.06.2026). Atos разворачивает Microsoft 365 E7 (Frontier Suite) для 56 000 сотрудников в 56 странах, а также 19 000 ИИ-агентов; единая плоскость управления на базе Entra/Defender/Intune/Purview/Agent 365. Уровень доказательности: первый (совместный пресс-релиз). Источник: 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 (открыт в сентябре 2025, развитие в H1 2026). Пятиэтапный процесс с гейтами /speckit.constitution → /specify → /plan → /tasks → /implement, плюс /clarify и /analyze; не привязан к конкретной модели (поддерживаются Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code). Уровень доказательности: первый. Источник: https://github.com/github/spec-kit

  • AWS Kiro (выпущен в июле 2025, развитие в H1 2026). Трёхэтапный рабочий процесс: требования → проектирование → задачи; spec запускает предопределённые действия агента; без написания spec работа невозможна. Уровень доказательности: первый. Источник: https://kiro.dev/

  • OpenAI Codex + AGENTS.md + Skills (2025–2026). Codex 2026.6 — более 5 млн еженедельных пользователей, из них 20% — не разработчики; AGENTS.md + Skills — комбинируемый набор инструкций. Уровень доказательности: первый (официальное объявление OpenAI). Источник: https://developers.openai.com/codex/skills

  • Claude Code (Anthropic, первое полугодие 2026). Система CLAUDE.md + .claude/rules/ + Skills; в феврале 2026 года появился в официальном маркетплейсе Anthropic; репозиторий Skills на GitHub — 112 тыс. звёзд; в феврале 2026 года в рамках раунда G раскрыта годовая выручка в размере 2,5 млрд долларов. Уровень доказательности: первый. Источник: https://code.claude.com/docs/en/claude-directory

  • JetBrains AI Pulse Survey (2026.1). Опрос более 10 000 профессиональных разработчиков по всему миру, локализован на 8 языках; Claude Code: CSAT 91% / NPS 54 (самый высокий показатель в отрасли); adoption rate Claude Code на рабочих местах — 18% (рост в 6 раз за 9 месяцев, с 3%), в Северной Америке — 24%; Copilot — 29% adoption на рабочих местах, но рост停滞; Cursor — 18%. Уровень доказательности: первый. Источник: https://www.jetbrains.com/lp/tools/ai-tools/

  • Pragmatic Engineer Newsletter (2026.2). Опрос 15 000 разработчиков; 46% назвали Claude Code «самым любимым инструментом», Cursor — 19%, Copilot — 9%. Уровень доказательности: первый. Источник: https://newsletter.pragmaticengineer.com/

  • Alibaba Qoder (2025.8 → 2026.7). Выпущен Alibaba в августе 2025 г.; 15.05.2026 Qoder 1.0 обновлён до Autonomous Agent Development Workbench; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; 28.05.2026 — Cloud Agents (управляемая среда выполнения агентов); 21.07.2026 — Qoder Security; май 2026 г. — более 5 млн пользователей по всему миру; интеграция с DingTalk CLI; 20.05.2026 — Tongyi Lima переименован в Qoder CN. Уровень доказательности: первый. Источники: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525

  • vibecoding.app / thebcms.com / tfir.io (первая половина 2026 г.). Пятиэтапные команды Spec Kit, сравнительный обзор SDD-инструментов, нотация EARS. Уровень доказательности: второй (сторонние обзоры). Источник: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development

  • EU AI Act / Code of Practice (полное применение с 2 августа 2026 г.). Для высокорисковых ИИ-систем крайний срок соответствия — 2 августа 2026 г.; для существующих моделей GPAI — до 2 августа 2027 г.; штрафы до 35 млн евро или 7% глобальной выручки; ст. 9–15: управление рисками, управление данными, прозрачность документации, человеческий надзор, точность и устойчивость. Уровень доказательности: первичный (регламент + вторичный комплаенс-анализ). Источники: 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). 44% проблем возникают из-за отсутствия контекста. Уровень доказательности: вторичный (отчёт вендора). Источник: https://www.qodo.ai/reports/state-of-ai-code-quality/

Методы AI: Уроки из практики

Введение

В последние годы AI-технологии стали все более популярными в различных отраслях, включая телекоммуникации, финансовые услуги, производство и электронную коммерцию. В этой статье мы рассмотрим опыт использования AI-технологий в этих отраслях и расскажем о наиболее важных аспектах их внедрения.

AI-технологии в телекоммуникациях

В телекоммуникациях AI-технологии используются для улучшения качества обслуживания клиентов, повышения эффективности работы сети и снижения затрат. Например, компания AT&T использует AI-технологии для анализа данных о работе сети и прогнозирования потенциальных проблем.

AI-технологии в финансовых услугах

В финансовых услугах AI-технологии используются для улучшения безопасности транзакций, повышения эффективности работы с системы и снижения риска. Например, компания Visa использует AI-технологии для анализа данных о транзакциях и выявления потенциальных мошеннических операций.

AI-технологии в производстве

В производстве AI-технологии используются для улучшения качества продукции, повышения эффективности работы и снижения затрат. Например, компания Toyota использует AI-технологии для анализа данных о производстве и прогнозирования потенциальных проблем.

AI-технологии в электронной коммерции

В электронной коммерции AI-технологии используются для улучшения качества обслуживания клиентов, повышения эффективности работы сети и снижения затрат. Например, компания Amazon использует AI-технологии для анализа данных о работе сети и прогнозирования потенциальных проблем.

Заключение

AI-технологии имеют широкий спектр применения в различных отраслях, включая телекоммуникации, финансовые услуги, производство и электронную коммерцию. Внедрение AI-технологий может привести к улучшению качества обслуживания клиентов, повышению эффективности работы и снижению затрат.

Ресурсы

Примечания

  • В этой статье мы рассмотрим опыт использования AI-технологий в различных отраслях.
  • AI-технологии имеют широкий спектр применения в различных отраслях.
  • Внедрение AI-технологий может привести к улучшению качества обслуживания клиентов, повышению эффективности работы и снижению затрат.
]]> AI-код: 1,7× больше ошибок, 2,74× больше уязвимостей — AI не видит ваших правил. Spec Kit, Kiro, Codex, Claude Code, Qoder переходят 2026 H1 на CLAUDE.md. 【Spec-Driven】Spec-Driven Development — Escrever especificações é a ação de engenharia com maior ROI na era da IA — A transformação da engenharia de software na era da IA — Aprendendo IA Devagar 177 https://iaiuse.com/pt/posts/spec-driven-development-escrever-especificacoes-e-a-acao-de-engenharia-de-maior-roi-na-era-da-ia 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z Fontes de dados: CodeRabbit 2025.12 / New Relic 2026 Relatório, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms Anúncio, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse.

Exemplos são cenários representativos, não se referem a empresas específicas.

Seu maior erro não é não ter comprado ferramentas, é não ter escrito o CLAUDE.md

Um CIO de um grande banco brasileiro me reclamou: “Compramos ferramentas de IA, implantamos modelos, treinamos as pessoas, mas nos primeiros seis meses de 2026, o ciclo de entrega quase não mudou.” O responsável pelo grupo de sistemas centrais foi mais direto: “O código escrito pela IA é útil, mas precisamos reescrevê-lo a cada vez – ela não entende as regras do nosso banco, não entende os requisitos da LGPD nem da ANPD, não entende como se conectar ao nosso sistema legado de 30 anos.”

Observação: CLAUDE.md é um arquivo de documentação que contém informações sobre como usar a ferramenta de IA Claude.

Aprendendo IA Devagar 001

Sem regras, a IA não é uma ferramenta poderosa

Nos últimos anos, temos discutido as capacidades poderosas da IA, mas parece que ignoramos uma questão crítica: sem regras, a IA não é uma ferramenta poderosa. Segundo a pesquisa da CodeRabbit, em dezembro de 2025, a análise de 470 PRs open source mostrou que PRs com colaboração de IA continham em média 10,83 problemas, enquanto PRs puramente humanos continham apenas 6,45 — o que significa que PRs com colaboração de IA têm 70% mais bugs que PRs humanos.

Os dados de 2026 também não inverteram essa tendência. A New Relic descobriu no relatório “2026 State of AI Coding Report” que 78% das equipes relataram mais incidentes após o deploy de código de IA. 62% dos líderes técnicos admitem que suas equipes “enviam com confiança, sem revisar linha por linha” o código de IA. Esses dois conjuntos de dados apontam para o mesmo problema: a IA não tem falta de capacidade, tem falta de contexto.

Em meio a todas as narrativas sobre “aceleração da transformação com IA”, precisamos considerar uma questão crítica: sem regras, a IA não é uma ferramenta poderosa. Precisamos estabelecer padrões e processos claros para garantir que o uso da IA seja seguro e confiável.

Casos

  • A experiência da operadora de telecomunicações Vivo mostra que estabelecer padrões e processos claros de uso de IA pode melhorar significativamente a qualidade e a segurança do código.
  • O caso do banco Itaú demonstra que, ao estabelecer processos e padrões de uso de IA, é possível reduzir significativamente o número de bugs e aumentar a segurança do código.
  • No setor de manufatura, o caso da Volkswagen mostra que a empresa conseguiu melhorar significativamente a qualidade e a segurança do código ao estabelecer padrões e processos de uso de IA.
  • No e-commerce, o caso do Magazine Luiza mostra que, ao estabelecer processos e padrões de uso de IA, foi possível melhorar significativamente a qualidade e a segurança do código.

Conclusão

Sem regras, a IA não é uma ferramenta poderosa. Precisamos estabelecer padrões e processos claros para garantir que o uso da IA seja seguro e confiável. Por meio de aprendizado e prática, podemos construir um ambiente de IA mais seguro e confiável.

Aprendendo IA Devagar: Avanços globais dos agentes de IA

No primeiro trimestre de 2026, grandes consultorias e gigantes de tecnologia do mundo todo avançaram na aplicação de agentes de IA. Reunimos os progressos e os contraexemplos:

BlocoProgressos (2026 H1)Contraexemplos (2026 H1)
EYMicrosoft 365 Copilot implantado para 150.000 colaboradores, economizando 2,5 milhões de horas, equivalente a US$ 250 milhões; expansão posterior para 400.000 colaboradores no mundo todoAdmite ao mesmo tempo que a premissa de 95% de aceleração e queda de 37% nos custos de operação financeira é “normatização primeiro”
AtosImplantação em 54 países, cobrindo 56.000 colaboradores; operação simultânea de 19.000 agentes de IA, com plano unificado de identidade, segurança, conformidade e governançaAderência estrita ao princípio “primeiro colocar a governança do Agent 365 em produção, depois expandir a escala”
Microsoft (própria)Relatório 2026 Work Trend Index: 82% dos líderes planejam expandir a força de trabalho com agentes de IA em 12 a 18 mesesAdmite ao mesmo tempo “o ritmo da mudança organizacional está atrás do uso individual” — a contradição central do conceito de Frontier Firm

Observe que a aplicação do Microsoft 365 Copilot já se expandiu para 400.000 colaboradores no mundo todo, economizando tempo e custos significativos. No entanto, Atos e a própria Microsoft também admitem que a aplicação de agentes de IA precisa seguir normas e princípios de governança estritos para garantir sua segurança e eficácia.

Aprendendo IA Devagar 001: A inevitabilidade do desenvolvimento orientado por padrões

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

Os dois conjuntos de dados comparativos demonstram um fato: sem normas, escalar é multiplicar o risco por N. O “rápido” de EY, Atos e Microsoft não se refere à velocidade do modelo, mas à capacidade da organização de responder rapidamente à pergunta “como usar IA”. Este é o cenário em que o Spec-Driven Development (SDD, desenvolvimento orientado por especificações) se consolidou como corrente dominante no primeiro semestre de 2026 — não porque engenheiros prefiram documentação, mas porque, sem escrever normas, não é mais possível sobreviver em um ambiente com 19.000 agentes.

Este artigo explicará com clareza três coisas: 1) por que os defeitos do código de IA são mais de 1,7 vez piores que os humanos; 2) como as cinco plataformas GitHub, AWS, OpenAI, Anthropic e Alibaba convergiram para o mesmo paradigma no primeiro semestre de 2026 — usar documentação para restringir o comportamento da IA; 3) por que o desenvolvimento orientado por especificações é capacidade organizacional, não escolha de ferramenta, e as três fases de implementação no primeiro semestre de 2026.

Código de IA vs código humano: distribuição de defeitos (análise de 470 PRs de código aberto) Relatório CodeRabbit 2025.12 ｜ todos os números são múltiplos relativos IA / humano (linha de base 1.0)

Comprimento da barra = múltiplo de defeitos de IA em relação ao humano; linha de base 1.0× = nível humano

Linha de base 1.0×

Total de problemas

1.7×
IA 10.83 vs humano 6.45 / PR

Erros de lógica / correção

1.75×

Qualidade de código / manutenibilidade

1.64×

Achados de segurança (combinado)

1.57×

Tratamento inadequado de senhas

1.88×

Vulnerabilidades XSS

2.74×
↑ Máximo

Código de IA sem restrições normativas é superior ao humano em todas as dimensões
Financeiro/telecom = conciliação de conformidade, gestão de senhas, criptografia de campos sensíveis — IA não enxerga nada disso

I - A Falha em AI não é um problema de modelo, é um problema de contexto

Um relatório da CodeRabbit foi citado várias vezes com a seguinte frase: “A AI carece de lógica de negócios local: os modelos seguem padrões de código estatísticos, em vez de compreender a semântica. Sem restrições rigorosas, eles passam por cima das regras sistemáticas internalizadas pelos engenheiros experientes.”

Essa frase explica por que a própria CodeRabbit, uma empresa que desenvolveu uma plataforma de AI para revisão de código (especializada em revisão de código de AI), foi capaz de identificar essa tendência antes dos outros. “O descobrimento mais crítico” não foi o número total, mas sim a distribuição:

  • Lógica/Certeza +75%: erros de lógica de negócios, erros de dependência, erros de fluxo de controle, erros de configuração - esses problemas podem não ser expostos em testes, mas podem causar acidentes em ambiente de produção.
  • Qualidade do código +64%: incoerência de nomes, estrutura não clara, violação de padrões de projeto - é essa a “maior categoria de diferença”. Um engenheiro experiente pode ver com um olhar que “essa não é a nossa forma de escrever”.
  • Segurança +57% (XSS com o maior valor de 2,74 vezes): tratamento inadequado de senhas (1,88 vezes), referência de objetos não seguros (1,91 vezes), vazamento de informações sensíveis, deserialização não segura (1,82 vezes) - não é se a AI pode ser usada, é se a AI pode ser liberada.

O problema não é que a IA não seja boa o suficiente. É que ela não enxerga.

Voltando ao ponto crítico real daquele CIO, três falhas concretas da IA em sistemas financeiros centrais:

Primeiro, a IA não enxerga 30 anos de lógica de conciliação. As regras de risco do banco estão escritas em stored procedures do sistema central — escritas há 30 anos, ninguém lembra de todas. O código gerado pela IA parece logicamente correto, mas em produção dispara aquela checagem de conciliação que ninguém lembra que existe, fazendo o lote inteiro de transações falhar.

Segundo, a IA não enxerga as restrições de conformidade. Senha tem que passar pelo sistema de gerenciamento de chaves, campos sensíveis têm que ser criptografados em repouso, logs não podem imprimir informações do cliente — isso é exigência regulatória dura, escrita nas políticas internas. A IA não sabe disso. O código que ela gera até roda, mas não passa na auditoria de conformidade.

Terceiro, a IA não enxerga sua dívida técnica. Aquele sistema legado de 30 anos usa um protocolo de interface próprio, e a documentação se perdeu há muito tempo. A IA escreve o código seguindo o padrão RESTful genérico, sobe para produção e descobre que as interfaces não batem — duas semanas de retrabalho.

Voltando aos outros números da New Relic: 62% dos times “enviam código de IA com confiança, sem revisar”, e 78% reportaram mais incidentes após o deploy. Esses dois números juntos dizem o seguinte — a taxa de defeito do código de IA em si não é o problema; “eu não sei quais defeitos o código de IA tem” é que é o problema.

Cenário típico: um banco comercial de capital misto introduziu desenvolvimento assistido por IA para o módulo de controle de risco de seu sistema central. Em três meses, a taxa de rejeição na revisão de conformidade subiu significativamente — os principais problemas eram regras internas como gerenciamento de senhas, criptografia de campos sensíveis e conformidade de logs. Essas regras estavam documentadas em manuais internos, mas a IA não as enxergava. Depois, a equipe converteu as regras centrais em um arquivo CLAUDE.md, e a taxa de rejeição caiu drasticamente.

2. As cinco principais plataformas no 1º semestre de 2026: convergência rumo ao “modelo orientado por especificações”

Em julho de 2025, o GitHub lançou o Spec Kit; no início de 2026, AWS Kiro, OpenAI Codex e Anthropic Claude Code completaram suas implementações; em maio de 2026, o Alibaba Qoder incorporou o “Spec-Driven Workflow” ao seu posicionamento de produto. No primeiro semestre de 2026, as cinco plataformas convergiram para o mesmo paradigma — usar documentação para restringir o comportamento da IA. Isso não é invenção de uma empresa específica, mas a resposta coletiva da indústria à “crise de qualidade do código gerado por IA”.

Caminhos orientados por normas das cinco grandes plataformas (2025-2026 H1) GitHub Spec Kit Código Aberto 2025.9 constitution.md Gate de cinco estágios: constitution → specify → plan → tasks → implement Independente de modelo, suporta 8+ agentes Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md Fluxo de três estágios: Requisito → Design → Tarefa spec-driven integrado ao fluxo da IDE Hooks disparam agentes automáticos Hooks de compliance/auditoria pré-instalados Sem spec, não inicia OpenAI Codex 2025-2026 AGENTS.md + Sistema de Skills Conjunto de instruções combináveis Config compartilhada em equipe 5M+ ativos semanais (2026.6) Não desenvolvedores: 20% De programação a agente universal Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + Habilidades (mercado oficial 2026.2) + Ecossistema MCP CSAT 91% / NPS 54 $2.5B ARR（2026.2） 112 mil estrelas no GitHub Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Modo Quest de execução autônoma + Modo Especialista em equipe + RepoWiki de contexto Mais de 5 milhões de usuários globais (2026.5) 2026.7.21 Qoder Security CLI DingTalk já integrado Paradigma comum: escrever explicitamente "como colaboramos com IA" como documento, no repositório Todos e todos os agentes de IA trabalham com a mesma especificação — essa é a essência da orientação por especificação

Vejamos as novidades de cada plataforma no 1º semestre de 2026:

GitHub Spec Kit: implementação de referência, portão de cinco estágios. Lançado em setembro de 2025, tornou-se a implementação de referência do setor até o primeiro semestre de 2026. 5 comandos principais + 2 complementares: /speckit.constitution (princípios inegociáveis), /speckit.specify (o que fazer e por quê), /speckit.plan (como mudar), /speckit.tasks (decomposição de tarefas), /speckit.implement (execução), além de /clarify e /analyze. Seu design-chave é o agnosticismo de modelo — os mesmos arquivos spec/plan/tasks não ficam vinculados a um agente de execução específico; Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf e Qwen Code podem todos se conectar. Isso o transformou em um “protocolo SDD de nível organizacional”, e não em um produto exclusivo do GitHub (avaliação vibecoding.app, junho de 2026, pontuação 0,816, fonte secundária).

AWS Kiro: A disciplina orientada por especificações, diretamente no seu IDE. Lançado em julho de 2025, o Kiro evoluiu para uma IDE de agente completa no primeiro semestre de 2026. Seu fluxo de trabalho é estruturado em três fases: requisitos → design → tarefas. A diferença crucial em relação ao Spec Kit está nos “ganchos” — os arquivos de especificação do Kiro podem acionar ações de agente predefinidas, incorporando etapas que dependem de sistemas externos, como conformidade, auditoria e implantação, diretamente no fluxo de trabalho. Se o seu objetivo é impor que o time escreva especificações, o Kiro é a escolha certa — porque sem um spec, o Kiro simplesmente não inicia. (Fonte: AWS Kiro oficial, julho de 2025; documentação Kiro.dev, 2026).

OpenAI Codex: AGENTS.md + Skills combináveis. Em 2025-2026, o AGENTS.md foi empurrado para o centro do ecossistema. Skills são a extensão-chave do primeiro semestre de 2026: pré-montam etapas como “ler planilha Excel”, “gerar SQL” e “rodar migração de dados”, que podem ser acionadas como blocos de montar. O uso semanal do Codex já passou de 5 milhões em junho de 2026, sendo 20% não-desenvolvedores — um sinal que muita gente ignora: a adoção orientada por padrões não é mais só coisa de time de engenharia, é coisa de todo mundo. Produto, operações e compliance estão todos escrevendo AGENTS.md (anúncio da OpenAI em 02/06/2026; review da thebcms.com em 2026, score 0.801).

Claude Code: CLAUD.md + .clad/rules/ + Skills. A Anthropic chama o arquivo de instruções do projeto de CLAUDE.md (que entrou no mercado oficial em fevereiro de 2026), .claude/rules/ (regras organizadas por diretório) e Skills (fluxos de trabalho compartilháveis). Claude Code foi a ferramenta com maior satisfação entre desenvolvedores no 1º semestre de 2026 — a pesquisa da JetBrains 2026.1 apontou CSAT de 91% e NPS de 54, com dois levantamentos independentes (Pragmatic Engineer 2026.2) chegando ao mesmo resultado. É a maior pontuação da indústria atualmente na categoria de ferramentas de programação com IA (uvik.net 2026.5, score 0.956, compilação de fontes primárias). A Clude Code saiu de zero para US$ 2,5 bilhões em receita anualizada em nove meses (dados da rodada G da Anthropic, fev. 2026) e tem 112 mil estrelas no GitHub (repositório de Skills) — os desenvolvedores votaram com os pés, e isso mostra o valor real de uma abordagem orientada por regras.

Alibaba Qoder: conformidade e regulação como motor no mercado chinês. Lançado em agosto de 2025 e atualizado para a versão 1.0 em 15 de maio de 2026, o Qoder deixou oficialmente de ser uma “IDE de IA” para se posicionar como um “Ambiente de Desenvolvimento de Agentes Autônomos”. Seu fluxo de trabalho orientado por especificações (Spec-Driven Workflow) foi apresentado ao lado de outros recursos de peso, como o Quest Mode (tarefas autônomas multiarquivo), o Expert Mode (equipes de especialistas em paralelo) e o RepoWiki (grafo de conhecimento do repositório). Em 28 de maio de 2026, a ferramenta ganhou o Cloud Agents, um runtime de agentes totalmente gerenciado; em 21 de julho, foi a vez do Qoder Security, voltado a conformidade e segurança; e no mesmo mês, chegou a versão Mobile (Android/iOS/HarmonyOS). Em maio de 2026, o Qoder já ultrapassava a marca de 5 milhões de usuários globalmente, e o DingTalk CLI o lista como um dos ambientes de execução de agentes suportados (Yahoo Finance 2025; Alibaba Cloud oficial 2026; Baidu Baike, jul. 2026).

Paradigma comum: escrever explicitamente “como colaboramos com a IA” em um documento, colocá-lo no repositório e fazer com que todas as pessoas e todos os agentes de IA trabalhem com base na mesma especificação. Os detalhes de implementação variam entre as cinco plataformas (nomes de arquivos/número de fases/mecanismos de hook), mas o objetivo é exatamente o mesmo.

Por que isso está acontecendo de forma concentrada no primeiro semestre de 2026? Porque a barreira de capacidade da IA já foi superada — com agentes autônomos do Claude Code, multiagentes paralelos do Codex e refatoração multiarquivo do Cursor, a IA deixou de ser uma “ferramenta de autocomplete” para ser um “colega de trabalho”. O documento de integração que você daria a um novo colega precisa ser legível também para a IA.

3. Direção por especificações é capacidade organizacional, não escolha de ferramenta

Este é o ponto mais importante para quem toma decisões. Direção por especificações não é escolher uma ferramenta — é definir “como a nossa organização colabora com a IA”. Se você escolhe o GitHub Spec Kit ou o Claude Code não importa; o que importa é se você documentou a especificação, colocou-a no repositório e fez com que todas as pessoas e todas as IAs trabalhem a partir dela.

Sem isso, a melhor ferramenta do mundo só faz o time acumular dívida técnica mais rápido.

Colocando isso no contexto da implantação em escala no primeiro semestre de 2026, as evidências são ainda mais sólidas. No retrospecto do ano fiscal de 2026, divulgado em julho, a Microsoft tratou os casos da EY e da Atos como modelos de “Frontier Firm” — não porque os modelos fossem novos, mas porque ambas as empresas responderam primeiro à pergunta “como usar IA”:

EY: governança primeiro, escala depois. Entre 2024 e 2025, a EY levou o Microsoft 365 Copilot a 150 mil pessoas, economizando 2,5 milhões de horas e cerca de US$ 250 milhões. O pré-requisito foi estabelecer a estrutura de governança de IA antes de qualquer expansão: a EY unificou sua stack com Power Platform, Copilot Studio, Azure, Foundry e Fabric, colocando conformidade, auditoria e governança em uma base única. Foi isso que viabilizou os ganhos posteriores: 95% de aceleração em determinados processos, redução de 37% nos custos de operação financeira e queda de até 90% em fluxos de trabalho manuais. O vice-presidente da EY foi direto no AI Tour de 2026: “Não implantamos IA e depois corrigimos a governança — construímos a governança primeiro e só então escalamos a IA”.

Atos: um plano de controle unificado para 19.000 agentes. A Atos foi uma das primeiras organizações do mundo a implantar o Microsoft 365 E7 (Frontier Suite), levando o Copilot a 56.000 funcionários em 54 países. Ao mesmo tempo, opera 19.000 agentes de IA — desde TI interna, unidades de negócios até projetos de clientes, todos construindo agentes com Foundry + Copilot Studio. O segredo do sucesso da Atos está em “um único plano de controle”: Entra (identidade) + Defender (segurança) + Intune (dispositivos) + Purview (conformidade) + Agent 365 (governança de agentes), tudo integrado. Essa abordagem integrada, quando traduzida para o setor financeiro, equivale a algo como “classificação de segurança + avaliação de exportação de dados + registro de algoritmos + auditoria + governança de modelos” — ou seja, uma arquitetura de governança, não apenas uma ferramenta de IA.

O paradoxo da mudança organizacional da Microsoft. No relatório 2026 Work Trend Index, a própria Microsoft admitiu: “o ritmo da mudança organizacional está atrás do uso individual”. Entre os 20.000 usuários de IA pesquisados, 82% dos líderes planejam expandir a força de trabalho com agentes de IA em 12 a 18 meses, mas apenas 24% já concluíram a implantação em nível empresarial. 81% dos líderes preveem que os agentes de IA serão integrados de forma moderada ou significativa à estratégia de IA — mas, novamente, apenas 24% já o fizeram. Isso significa que a maioria das empresas está a 12 a 18 meses de distância entre “se preparar” e “efetivamente realizar”. Como preencher essa lacuna? A governança orientada por normas é o principal pilar de sustentação.

Fonte: Microsoft FY26 retrospective, 28/07/2026; Microsoft 2026 Work Trend Index Annual Report, 05/05/2026 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, fonte primária em PDF); análise da Futurum Group, 26/01/2026 (fonte secundária).

Insight 1: Investir em governança é alto ROI.

Os dados da CodeRabbit fornecem uma base clara para o cálculo de ROI: a taxa de problemas no código gerado por IA é aproximadamente 1,7 vez maior, e as vulnerabilidades de segurança são reduzidas em 2,74 vezes. Isso significa:

  • Menos retrabalho (no setor financeiro, um retrabalho de revisão de conformidade leva de 2 a 4 semanas)
  • Menos incidentes de segurança (multas regulatórias e danos à reputação em caso de vazamento de dados)
  • Menores custos de manutenção (uma redução de 40% na dívida técnica é um número comum)

Escrever um arquivo de especificação do projeto, como CLAUDE.md ou AGENTS.md, é a ação de engenharia com maior ROI na era da IA. O caso da EY mostra a conversão no mundo real — 150 mil pessoas usando Copilot, gerando uma economia de US$ 250 milhões. Vale notar: a EY não economizou porque a “ferramenta é poderosa”, mas porque “as especificações transformaram o valor da ferramenta em resultado concreto”.

Insight 2: Incorpore as especificações aos processos da organização, não dependa de iniciativas individuais.

Se as especificações existirem apenas na cabeça de um engenheiro sênior, elas se perdem quando há rotatividade de pessoal. É preciso consolidá-las em:

  • Documentação do repositório (AGENTS.md / CLAUDE.md / constitution.md)
  • Gate de CI (verificação automática de conformidade com as especificações)
  • Configuração compartilhada da equipe (o sistema de Skills permite que todo o time utilize)

Transformando Padrões em Ativos Organizacionais, Não Habilidades Individuais

Isso é especialmente crítico no setor financeiro — requisitos de conformidade, regras de segurança e políticas de negócio são ativos de nível organizacional, não a “experiência” de um engenheiro específico. Os 19.000 agentes da Atos operam em 54 países porque a governança não é “alguém que entende do assunto”, mas sim “imposição sistêmica”.

Insight 3: Gatekeeping importa mais do que velocidade.

Os gates de cinco estágios do GitHub Spec Kit (constitution → specify → plan → tasks → implement), a regra do Claude Code de “não escrever código antes que os testes falhem” e a exigência do Kiro de “não iniciar sem um spec” estão todos fazendo a mesma coisa: adicionar um “freio” entre a IA e o resultado final. Cada etapa produz artefatos auditáveis (spec.md, plan.md, tasks.md) que podem ser rejeitados ou modificados antes da geração de código.

Quanto mais autônoma a IA, mais ela precisa de gatekeeping. O Change Advisory Board (Change Advisory Board (CAB)) no setor financeiro, os processos de registro de algoritmos e as avaliações de segurança (ISO 27001 + auditorias da ANPD) são, essencialmente, gates adicionados antes da produção. O código gerado por IA também precisa de gates semelhantes, apenas em formatos diferentes. Os 62% de equipes no relatório da New Relic 2026 que “confiantemente publicam sem revisão” estão pagando por essa confiança com uma taxa de incidentes significativamente maior (78%).

Três fases de implementação de normas no setor financeiro (versão prática 2026 H1) Fase 1: Inventariar regras 2-4 semanas | mais demorado, maior ROI Lista de requisitos de conformidade (etc.) Regras de segurança (senha/criptografia/logs) Regras de negócio (risco/transações/cobrança) Restrições técnicas (interfaces antigas/limitações de versão) Governança de fornecedores (contrato/auditoria/responsabilidade) Reunir regras espalhadas Organizar em documentação estruturada Fase 2: implementar no repositório 1-2 semanas | colocar no repositório, IA carrega automaticamente CLAUDE.md / AGENTS.md constitution.md Definição de Skills (fluxos de trabalho compartilháveis) Design de processo de gate (cinco fases) .claude/rules/ (regras em camadas) Colocar regras no repositório, IA carrega automaticamente Fase 3: institucionalização Contínuo | de ferramenta a capacidade organizacional Gate de CI (revisão automática) Configuração compartilhada da equipe (Skills) Mecanismo de atualização periódica (revisão trimestral) Métricas (taxa de defeitos/taxa de conformidade) Governança de agentes (Agente 365 nível 1) Padrões tornam-se ativos organizacionais, Sem dependência de indivíduos

A primeira fase consome mais tempo, mas tem o maior ROI
Na maioria das instituições financeiras, as regras estão dispersas em documentos/e-mails/mentes; a primeira organização leva de 3 a 8 semanas

Quatro. As Três Fases Reais de Implementação no 1º Semestre de 2026

Usando o setor financeiro como exemplo, este é o caminho em três fases — setores igualmente regulados podem usar como referência. A prática da EY e da Atos no 1º semestre de 2026 corresponde exatamente a essas três fases.

Fase 1: Inventário de Regras (2–4 semanas).

É a fase que mais consome tempo, mas também a de maior ROI. Trata-se de localizar todas as regras dispersas:

  • Requisitos de conformidade: a linha de base mínima para o setor financeiro = Dengbao Nível 3 (classificação de proteção de segurança cibernética da China) + avaliação de exportação de dados transfronteiriços + registro de algoritmos (sem um desses três, não implemente IA). Acima disso, há ainda regras de reporte regulatório, proteção de informações de clientes, restrições de fluxo de dados transfronteiriços e definição de quais dados podem ser expostos à IA
  • Regras de segurança: gerenciamento de senhas, padrões de criptografia, tratamento de campos sensíveis, requisitos de logs
  • Regras de negócio: limites de risco, condições de sinistro, restrições de transação, lógica de cobrança
  • Restrições técnicas: interfaces de sistemas legados, nomenclatura de bancos de dados, limitações de versão de frameworks
  • Governança de fornecedores: como exigir contratualmente que fornecedores usem nossos padrões e como auditar o uso de IA por eles

Cenário típico: durante a fase de levantamento, uma corretora de valores descobriu que as regras estavam espalhadas por dezenas de documentos Word, wikis do JIRA, e-mails pessoais e planilhas Excel — só depois de organizar tudo é que se obteve uma lista estruturada de regras. A abordagem da Atos é mais sistemática: eles simplesmente dividem as regras em cinco categorias — “conformidade, segurança, negócio, tecnologia e fornecedores” — cada uma com seu próprio fluxo de governança, todas conectadas ao plano de controle do Agent 365.

Isso não é trabalho técnico, é trabalho organizacional — você precisa reunir os departamentos de conformidade, segurança e negócio para escrever as regras que todos aceitam. Na primeira vez, uma organização financeira normalmente leva de 3 a 8 semanas — mas isso é um ativo organizacional permanente.

Fase 2: Versionamento no repositório (1–2 semanas).

Transforme as regras da Fase 1 em documentos e coloque-as no repositório. O GitHub Spec Kit usa constitution.md, o Claude Code usa CLAUDE.md, o OpenAI Codex usa AGENTS.md, e o Alibaba Qoder usa o Spec Workflow. Os nomes dos arquivos diferem, mas o objetivo é o mesmo — fazer com que a IA carregue as regras no momento em que abre o repositório.

Estrutura sugerida (formato dominante no 1º semestre de 2026):

  • Visão geral do projeto: o que este sistema faz e a quem atende
  • Princípios inegociáveis: limites de segurança, conformidade e regras de negócio intransigentes
  • Stack tecnológico e restrições: frameworks, bancos de dados e padrões de interface adotados
  • Padrões de código: convenções de nomenclatura, estrutura de diretórios e cobertura mínima de testes (sem impor ritmo de TDD — basta especificar a cobertura, os caminhos obrigatórios e as áreas proibidas; TDD é uma escolha organizacional, não um requisito normativo)
  • Regras de negócio: lógica de risco, regras de transação e critérios de faturamento
  • Requisitos de conformidade: certificação ISO 27001, transferência internacional de dados (LGPD Art. 33-36), reporte regulatório ao Banco Central do Brasil e necessidade de avaliação do PL 2338/2023 para algoritmos de IA generativa
  • Diretrizes de uso de IA: cenários permitidos, cenários que exigem revisão humana obrigatória e regras para dados que cruzam fronteiras
  • Governança de fornecedores: cláusulas contratuais, mecanismos de auditoria e definição de responsabilidades

Apêndice: esqueleto do CLAUDE.md para o setor financeiro (~200 linhas, pronto para fork e adaptação)

Abaixo está um esqueleto de CLAUDE.md voltado à modernização do core bancário de um banco comercial de capital misto, organizado na ordem “princípios inegociáveis → requisitos de conformidade → diretrizes de uso de IA → regras de negócio → restrições de engenharia”. Sua empresa não precisa começar do zero — basta preencher os campos em aberto com as regras específicas de vocês.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
# CLAUDE.md — <nome do sistema> — regras de colaboração com IA

> Âmbito de aplicação: <nome do sistema> v<versão>, todos os agentes de IA (Claude Code / Cursor / Copilot / Codex)
> que trabalham neste repositório devem cumprir esta especificação. Este ficheiro é mantido pelo <comitê de governança>,
> com revisão trimestral.
> Última atualização: YYYY-MM-DD

## 1. Visão geral do projeto
- **Posicionamento de negócio**: nome do sistema central / segmentos de clientes / principais tipos de transação
- **Cadeia crítica**: transação → controlo de risco → liquidação → reconciliação → relatórios regulatórios
- **Janela de indisponibilidade**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (qualquer alteração proibida)
- **Dependências principais**: sistema <X> a montante, sistema <Y> a jusante, plataforma de relatórios regulatórios

## 2. Princípios inegociáveis (linhas vermelhas — violação = recusa de merge)

### 2.1 Linhas vermelhas de segurança
- Palavras-passe, chaves e tokens passam obrigatoriamente pelo KMS (Key Management Service) — **hardcoding proibido**, **impressão em logs proibida**
- Campos sensíveis do cliente (BI / nº cartão / CVV / telemóvel) **devem ser cifrados em repouso**; texto em claro proibido na base de dados
- Proibido aparecer em logs: BI completo, nº cartão completo, palavra-passe em claro, combinação nome + telemóvel do cliente
- Chamadas a APIs externas têm obrigatoriamente de passar pelo API gateway; ligação direta proibida

### 2.2 Linhas vermelhas de conformidade
- Código gerado por IA que envolva acesso a dados do cliente deve indicar "acesso a dados: <campo>" na descrição da PR
- Transferência transfronteiriça de dados proibida; **qualquer saída de dados tem de passar por avaliação de transferência transfronteiriça de dados** (contactar o departamento de conformidade)
- Decisões algorítmicas (crédito / tarifação de seguros / antifraude) devem manter uma porta de revisão humana
- Alterações de modelo requerem registro de algoritmos; o nº registro tem de ser citado na descrição da PR

### 2.3 Linhas vermelhas de negócio
- Alterações de limiares de controlo de risco requerem assinatura dupla do responsável de risco e do responsável de negócio
- Operações que envolvam fundos de clientes têm de ter design idempotente + rollback em caso de falha
- Alterações de limites de transação, tarifas e parâmetros de produto passam pela plataforma de gestão de parâmetros; nenhum hardcoding no código

## 3. Stack tecnológico e restrições
- **Linguagens**: Java 17 (núcleo) / Kotlin (novos módulos) / SQL (base de dados)
- **Framework**: Spring Boot 3.x + Spring Cloud Alibaba
- **Base de dados**: OceanBase 4.x (modo compatível MySQL), **chaves estrangeiras proibidas**
- **Normas de interface**: gRPC obrigatoriamente em interno; OpenAPI 3.0 para interfaces externas; RESTful apenas para interfaces administrativas
- **Convenções de nomenclatura**: classes Java em PascalCase, métodos em camelCase, constantes em UPPER_SNAKE; nomes de tabelas `t_<domínio>_<entidade>`; índices `idx_<tabela>_<campo>_<ordem>`
- **Estrutura de pacotes**: `com.<empresa>.<domínio>.<subdomínio>.<camada>` (ex.: `com.bank.pay.tx.core.service`)

## 4. Padrões de código
- **Cobertura mínima de testes**: cadeia crítica ≥ 80%, utilitários ≥ 60%; nova entrega via PR tem de incluir testes
- **Caminhos obrigatoriamente testados**: todos os controllers precisam de testes de integração (incluindo caminhos de falha); todas as branches de enums precisam de testes unitários
- **Caminhos proibidos**: proibição de modificar o diretório `<módulos de legado>` — criar primeiro uma camada de adaptação
- **Gestão de dependências**: novas dependências de terceiros requerem análise SCA + aprovação de segurança

## 5. Regras de negócio (por domínio)
### 5.1 Transações
- Limite unitário: <valor>; limite diário: <valor>; excedentes passam por aprovação manual
- Janela horária de transação: <HH:MM> ~ <HH:MM>
- Deteção de transações duplicadas: mesmo <campo> dentro de <janela temporal> = duplicado

### 5.2 Controlo de risco
- Ordem de prioridade das listas negras: lista interna → listas emitidas pelo regulador → bloqueio judicial
- Limiar de saída do modelo antifraude: <pontuação>; acima do limiar, dupla revisão humana obrigatória

### 5.3 Faturação
- Alterações de tarifas têm de ter nº de versão + data de entrada em vigor
- Encomendas históricas calculadas pela tarifa em vigor na data de entrada em vigor, sem retroatividade

## 6. Requisitos de conformidade
- 等保三级 (MLPS Nível 3): <órgão regulador>, <data da próxima avaliação>
- Avaliação de transferência transfronteiriça de dados: âmbito de aplicação (apenas módulos de negócio transfronteiriço)
- Registro de algoritmos: âmbito de aplicação (crédito / tarifação de seguros e outros algoritmos críticos), nº registro `<nº registro>`
- Relatórios regulatórios: tabela de mapeamento de campos CBIRC / Banco Popular da China em `<caminho>`

## 7. Padrões de uso de IA
- **Cenários em que a IA pode ser usada**: templates CRUD, geração de testes unitários, rascunhos de documentação, sugestões de otimização SQL
- **Cenários que exigem revisão humana obrigatória**: lógica de controlo de risco, regras de faturação, gestão de permissões, cifragem / decifragem, dados transfronteiriços
- **Cenários em que a IA não pode atuar sozinha**: dossiês de aprovação Change Advisory Board (CAB), execução de mudanças em produção, resposta a emergências
- **Regras de saída de dados**: dados de treino / prompts / logs de saída nunca saem do país; priorizar versões de implementação localizada (<fornecedor>)
- **Requisitos de auditoria**: todo o código gerado por IA deve indicar "assistência IA: <nome da ferramenta>" na descrição da PR

## 8. Governança de fornecedores
- **Admissão de fornecedores**: fornecer relatório SOC 2 / ISO 27001; modelos de IA têm de fornecer model card
- **Cláusulas contratuais**: titularidade dos dados, explicabilidade dos modelos, cláusula de saída, direito de auditoria
- **Mecanismo de auditoria**: auditoria trimestral do uso de IA por fornecedores; auditoria mensal para fornecedores de alto risco

## 9. Governança e atualizações
- **Proprietário**: <comitê de governança> (conformidade + segurança + arquitetura + negócio)
- **Frequência de atualização**: revisão trimestral; mudanças de emergência por canal rápido (assinatura dupla + publicação 24h)
- **Registo de alterações**: ver `CLAUDE_CHANGELOG.md`
- **Tratamento de violações**: 1ª violação = aviso + formação obrigatória; 2ª violação = suspensão do uso de ferramentas IA; 3ª violação = revogação de permissões

Este esqueleto não é uma “resposta padrão”, é um “modelo de preenchimento”. O que importa não é quantas palavras você escreve, mas o que você coloca em cada campo — os espaços em branco revelam exatamente aquilo que sua empresa “ainda não pensou com clareza”.

Um cenário típico: o CLAUDE.md de um banco comercial define regras específicas para tratamento de senhas — quando o código gerado por IA envolve senhas, é obrigatório chamar a API interna de gerenciamento de chaves, sendo proibido hardcoding. Esse tipo de regra responde por uma parcela alta dos motivos de rejeição em auditorias de conformidade.

Um campo novo e importante no primeiro semestre de 2026 é Skills/definição de fluxos de trabalho — não apenas documentação, mas uma cadeia de ferramentas que a IA pode invocar. O sistema de Skills do Claude Code (que entrou no mercado oficial da Anthropic em fevereiro de 2026, com 112 mil stars no GitHub) transforma tarefas como “ler planilhas Excel”, “gerar SQL” e “executar migração de dados” em fluxos de trabalho compartilháveis. Essa é a evolução central da governança no primeiro semestre de 2026: governança não é só restrição, é fluxo de trabalho executável.

Terceira fase: institucionalização (contínua).

Escrever as diretrizes não é o fim — é o começo. É preciso transformá-las em parte dos processos da organização:

  • Gate de CI integrado: verificação automática de conformidade com as diretrizes (por exemplo, detectar senhas hardcoded ou campos sensíveis sem criptografia)
  • Configuração compartilhada entre times: usar o sistema de Skills para que todo o time opere com o mesmo conjunto de diretrizes
  • Mecanismo de atualização periódica: quando as regras mudam, as diretrizes precisam acompanhar (revisão trimestral)
  • Métricas e feedback: acompanhar taxa de defeitos em código gerado por IA, taxa de aprovação em revisões de conformidade e taxa de retrabalho
  • Governança de agentes: estender a governança de pessoas para agentes de IA — é exatamente isso que a Atos fez no Agent 365, elevando essa prática do nível individual para o nível sistêmico

EY e Atos, no primeiro semestre de 2026, trataram a terceira fase como “capacidade organizacional”. As 2,5 milhões de horas economizadas pela EY são resultado de ter acertado a primeira e a terceira fases — a segunda fase apenas traduziu as regras em documentos legíveis por IA.

Cinco — Variante de alta regulação: três abordagens de engenharia para incorporar conformidade

Em setores altamente regulados — finanças, telecomunicações, saúde — a adoção orientada por diretrizes enfrenta uma camada adicional de complexidade em comparação com setores em geral: conformidade não é um apêndice do processo, é código embutido. As três abordagens abaixo foram validadas no primeiro semestre de 2026 para incorporar conformidade, e servem de referência direta para CIOs e líderes de transformação digital no desenho organizacional.

5.1 Incorporando Representantes de Conformidade nos Stream Teams: Tornando a Conformidade “Presente” em vez de “Aprovação”

A abordagem tradicional: o time de desenvolvimento escreve o código, o time de conformidade revisa depois — quando os problemas são encontrados na revisão, o código já está em produção há duas semanas, e o custo de retrabalho é de 2 a 4 semanas. O problema central é que a conformidade fica no fim do processo.

A nova abordagem: incorporar representantes de conformidade em cada stream team, com uma estrutura de reporte duplo — “linha sólida” para o departamento de conformidade e “linha tracejada” para o time de negócio. O desenho concreto:

  • Alocação de headcount: 1 representante de conformidade para cada 6 a 8 stream teams, vinculado ao departamento de conformidade, mas com assento físico no time de negócio — não é um “empréstimo” temporário
  • KPIs na linha tracejada: 50% do peso dos KPIs do representante de conformidade está atrelado à “taxa de defeitos de conformidade” e à “taxa de aprovação na primeira revisão” do time de negócio, não apenas à “cobertura de auditoria” do departamento de conformidade
  • Envolvimento antecipado: o representante de conformidade participa das reuniões diárias (uma vez por semana já é suficiente), das revisões de PR, e o código gerado por IA deve passar pelo representante de conformidade antes do merge — não ser descoberto depois e corrigido às pressas
  • Suporte por ferramentas: o representante de conformidade utiliza Skills com checklists de conformidade, em vez de verificação manual item por item

Cenário típico: um banco comercial nacional, no primeiro semestre de 2026, pilotou 3 squads de fluxo com representantes de compliance incorporados, reduzindo a taxa de rejeição de código de IA por não conformidade de 35% para 8% — o ponto central não é o compliance “vigiar mais de perto”, mas sim “enxergar mais cedo”. O fator crítico dessa abordagem é que o reporte pontilhado dos representantes de compliance precisa estar alinhado aos objetivos de negócio — se o KPI do representante continuar sendo definido apenas pelo departamento de compliance, a incorporação está fadada ao fracasso.

5.2 Compliance como enabling team: transformar restrições em affordances

Abordagem tradicional: o time de compliance atua como “guardião”, e os times de negócio enxergam o compliance como “o departamento que complica”. Resultado: um jogo de soma zero entre as partes.

Nova abordagem: o time de compliance é reestruturado segundo o modelo de enabling team do Team Topologies — não escreve código diretamente, não revisa PRs diretamente, mas entrega três coisas para que os times de negócio possam se autosservir em conformidade:

  1. Verificações de conformidade no pipeline de CI: Transforme pontos de conformidade de alta frequência — como senhas hardcoded, campos sensíveis em texto puro, transferência transfronteiriça de dados e pontos de decisão algorítmica — em portões obrigatórios no GitHub Actions / GitLab CI. PRs do time de negócios disparam verificações automáticas; se não estiverem em conformidade, falham diretamente — sem necessidade de um representante de conformidade revisar manualmente.
  2. Requisitos regulatórios como affordances (restrições responsivas ao contexto): Por exemplo, ao desenvolver funcionalidades que envolvem dados de clientes, o plugin da IDE exibe um aviso como “este campo deve usar KMS”; ao escrever logs, o sistema detecta automaticamente se há informações sensíveis e emite alerta. Faça com que a conformidade seja uma “ação natural durante o desenvolvimento”, não um “ser informado do que foi violado antes do deploy”.
  3. Biblioteca compartilhada de Skills + treinamento de conformidade: O time de conformidade mantém uma coleção de “Skills de conformidade” que podem ser invocadas diretamente na integração de novos funcionários ou em mudanças de time — transformando o conhecimento de conformidade de “documento” em “ferramenta executável”.

Cenário típico: um banco regional chinês implementou, no primeiro semestre de 2026, portões de conformidade no CI + avisos de conformidade na IDE, reduzindo o tempo médio por pessoa na revisão de conformidade de código de IA de 45 minutos para 8 minutos por revisão. O ponto central não é a revisão de conformidade “ficar mais rápida”, é o código gerado por IA “já nascer sem erros”.

5.3 Conformidade em duas velocidades: alinhamento ao ritmo do negócio

O último detalhe: conformidade não pode ser tratada com “tamanho único”. Divida as regras em dois níveis de risco:

  • Regras de alto risco (envolvendo fundos de clientes / decisões algorítmicas / dados transfronteiriços / requisitos de segurança cibernética) seguem controle rigoroso: revisão humana obrigatória + confirmação secundária por IA + registro no Change Advisory Board (Change Advisory Board (CAB))
  • Regras de baixo risco (código CRUD padrão / código utilitário / geração de documentação) seguem autoatendimento: apenas verificação automática no CI, sem necessidade de revisão humana

O plano de controle do Agent 365 da Atos é essencialmente essa camada — agentes de diferentes níveis ficam vinculados a diferentes requisitos de governança. Ao estratificar as regras de conformidade por nível de risco, o time de negócios percebe que “conformidade não é um obstáculo em todo lugar”.

O que essas três coisas significam em conjunto: incorporar conformidade não é adicionar um processo, é redesenhar a estrutura e os incentivos do time. Se o seu departamento de conformidade ainda opera no modo “revisão a posteriori”, a adoção orientada por regras vai travar no estágio mais difícil — o da “institucionalização”. O departamento de conformidade precisa se transformar primeiro, para que a adoção orientada por regras do time de engenharia flua sem atritos.

Seção 6 — Perguntas que você pode estar se fazendo

“Já temos padrões de codificação. Qual é a diferença?”

Padrões de codificação tratam de “como escrever código”; a adoção orientada por regras trata de “como colaborar com IA”. Padrões de codificação não incluem: regras de negócio, requisitos de conformidade ou políticas de uso de IA. A adoção orientada por regras torna explícito o fluxo completo de colaboração entre humanos e IA — não é um guia de estilo de código.

“Escrever especificações vai desacelerar o desenvolvimento?”

No curto prazo, sim. No longo prazo, não. Os dados da CodeRabbit são claros: código gerado por IA sem restrições apresenta risco de defeitos aproximadamente 1,7 vez maior e 2,74 vezes mais vulnerabilidades de segurança. No setor financeiro, uma única rodada de retrabalho por não conformidade custa de 2 a 4 semanas — economizar uma dessas já paga um mês inteiro de escrita de especificações. Os US$ 250 milhões economizados pela EY são a prova real de que isso funciona quando vira capacidade organizacional.

“E se ninguém no nosso time souber escrever especificações?”

Você não precisa começar do zero. O GitHub Spec Kit, o Claude Code Superpowers e o AWS Kiro já vêm com templates prontos. Basta preencher com as regras específicas da sua organização — e a maioria delas são regras de compliance e segurança que os departamentos jurídico e de segurança já escreveram há muito tempo. Só que nunca foram colocadas num formato que a IA conseguisse ler.

“São tantas ferramentas de IA por aí… Qual escolher?”

Não importa. Escolham o que já usam. A norma é o que conduz — não está presa a nenhuma ferramenta: o CLAUDE.md funciona no Claude Code, no Cursor e no Codex; o AGENTS.md roda no ecossistema OpenAI; o constitution.md é agnóstico de modelo. O essencial é escrever a norma, não trocar de ferramenta. A EY está a implementar no ecossistema Microsoft, a Atos também — a diferença na escolha da ferramenta é apenas superficial; a unidade na arquitetura de governança é que é o cerne.

“Em agosto de 2026, o EU AI Act entra em pleno vigor — isso afeta-nos?”

Sim. O EU AI Act entra em plena aplicação em 2 de agosto de 2026, com requisitos obrigatórios de conformidade para sistemas de IA de alto risco (incluindo crédito, precificação de seguros, triagem de empregos e infraestruturas críticas) — gestão de risco (Art. 9), governança de dados (Art. 10), transparência documental (Arts. 11–13), supervisão humana (Art. 14) e precisão/robustez (Art. 15). As multas máximas chegam a 35 milhões de euros ou 7% do faturamento global. Para empresas chinesas que operam no exterior, o mercado europeu é uma questão obrigatória; para empresas domésticas, o arcabouço do EU AI Act também é o padrão mais referenciado globalmente — você pode não estar diretamente sujeito a ele, mas dificilmente contornará seus efeitos de transmissão sobre fornecedores, parceiros e operações transfronteiriças (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

“Comparação doméstica: a UE regula IA, e nós, o que regulamos?”

Domesticamente, a governança de IA generativa segue um tripé de “registro de algoritmos + revisão de corpus + avaliação de segurança”, com as Medidas Provisórias para a Gestão de Serviços de IA Generativa (em vigor desde agosto de 2023) como núcleo operacional. A maior diferença entre os dois não está nos detalhes das cláusulas, mas na filosofia legislativa:

DimensãoEU AI ActMedidas de Gestão de Serviços de IA Generativa da China
Posicionamento jurídicoRegulamento horizontal (aplica-se a todos os sistemas de IA)Regra vertical (focada em serviços de IA generativa)
Classificação de risco4 níveis (inaceitável / alto / limitado / mínimo)2 níveis (envolvendo segurança de opinião pública / uso comercial geral)
Momento da supervisãoEx-ante (registro já na fase de desenvolvimento)Ex-post (registro após lançamento + registro do algoritmo)
TransparênciaAlta (exige resumo das fontes de dados de treinamento e model cards)Média (exige conformidade dos dados de treinamento, mas não obriga divulgação das fontes)
Limite de penalidades7% da receita global ou €35 milhõesSuspensão do serviço / multas (geralmente múltiplos dos ganhos ilícitos)
Escopo de aplicaçãoTodas as empresas dentro do limite de receita globalTodos os sujeitos que oferecem serviços dentro do território chinês

Na prática, os sistemas de IA de instituições financeiras no Brasil normalmente estão sujeitos a três conjuntos de regras simultaneamente — a LGPD 13.709/2018 (camada de proteção de dados pessoais, sob a fiscalização da ANPD) + as normas do Banco Central do Brasil sobre crédito digital, open finance e gestão de risco (camada de negócio) + a Resolução CMN 4.658/2018 sobre política de segurança cibernética + a avaliação do PL 2338/2023 (regulamentação de IA em tramitação, camada de conformidade). Isso significa que, para fazer desenvolvimento orientado por normas no mercado brasileiro, não se pode simplesmente copiar o framework do EU AI Act — é preciso incorporar as três linhas de “conformidade de dados (LGPD) + reporte ao Bacen + adequação ao PL 2338/2023” diretamente no CLAUDE.md.

Para empresas que operam em Portugal ou no mercado europeu: os quatro pilares do EU AI Act — “gestão de risco + governança de dados + transparência documental + supervisão humana” — passaram a ser plenamente aplicáveis em 2 de agosto de 2026, e a CNPD (Comissão Nacional de Proteção de Dados) já atua como autoridade de referência para a conformidade em Portugal. Quem escreve normas compatíveis com o EU AI Act hoje tem alta probabilidade de estar alinhado também com o endurecimento regulatório brasileiro nos próximos 3 anos, na medida em que o PL 2338/2023 caminha em direção à mesma arquitetura europeia (PL 2338/2023 tramitação 2026; EU AI Act em plena aplicação em 2/8/2026).

7. Implicações para tomadores de decisão

Implicação 1: Escrever uma especificação de projeto em CLAUDE.md/AGENTS.md é a ação de engenharia com maior ROI na era da IA.

O investimento é de 3 a 8 semanas de organização + 1 a 2 semanas de documentação. O retorno: teto de risco de defeitos em cerca de 1,7x, redução de 2,74x em vulnerabilidades de segurança e queda de 40%+ na taxa de retrabalho. No setor financeiro, economizar uma única rodada de retrabalho em revisão de conformidade (2 a 4 semanas) já cobre esse custo. A EY implantou o Copilot para 150 mil pessoas e economizou US$ 250 milhões — mas só porque a padronização veio primeiro.

Insight 2: Padronização é capacidade organizacional, não escolha de ferramenta.

Se você escolhe o GitHub Spec Kit ou o Claude Code, tanto faz. O que importa é se você definiu “como a nossa organização colabora com IA”. Sem isso, a melhor ferramenta só faz o time gerar mais dívida técnica em menos tempo.

Insight 3: Incorpore a padronização nos processos da organização, não dependa de indivíduos.

Se a padronização vive só na cabeça de um engenheiro sênior, ela se perde quando há rotatividade. É preciso consolidá-la na documentação do repositório, em gates de CI, em configurações compartilhadas do time e em plataformas de governança de agentes. Faça da padronização um ativo organizacional, não uma habilidade pessoal. Os 19.000 agentes da Atos operam em 54 países porque a governança não é “alguém que entende” — é “o sistema que impõe”.

Insight 4: Gates de controle importam mais do que velocidade.

O gate de cinco estágios do GitHub Spec Kit, a regra “não escrever código antes que os testes falhem” do Superpowers e a exigência “não iniciar sem um spec” do Kiro fazem, no fundo, a mesma coisa: adicionar um “freio” entre a IA e o resultado final. Quanto mais forte a capacidade da IA, mais à frente a governança precisa correr. Os 78% de incidentes do relatório New Relic 2026 são o preço pago pelos 62% de times que “publicam sem revisar”. Os CIOs do setor financeiro no Brasil entendem isso melhor que ninguém: o Comitê de Mudanças (Change Advisory Board — Change Advisory Board (CAB)), os processos de avaliação de algoritmos e a adequação à LGPD/ANPD são todos gates posicionados antes do ambiente de produção. O código de IA precisa de gates semelhantes — e ainda mais a montante.

Autoavaliação reversa (não embeleze ao responder): o código gerado por IA na sua empresa costuma voltar da revisão de conformidade? Qual foi o último problema causado por código de IA? Se você perguntar ao líder técnico “como colaboramos com a IA”, ele consegue entregar um documento? Se você não consegue responder a nenhuma dessas três, a engenharia orientada por especificações ainda não está consolidada — escreva as especificações antes de comprar as ferramentas.

Três perguntas de coaching para os decisores

Por fim, três perguntas — não é um checklist, são perguntas que você pode usar diretamente na conversa com seu time:

  1. “Se todas as ferramentas de IA desaparecessem amanhã, quanto cairia a qualidade do código do seu time?” — Essa pergunta revela o valor real da engenharia orientada por especificações: se a resposta for “cairia significativamente”, suas especificações ainda não estão consolidadas; se for “quase nada”, a abordagem já está funcionando na prática.
  2. “No seu projeto de engenharia orientada por especificações, o departamento de compliance atua como ‘guardião’ ou como ‘facilitador’?” — Se a resposta for “guardião”, sua velocidade de entrega vai esbarrar em gargalos de aprovação; se for “facilitador”, vocês já estão no caminho certo descrito na seção 5.2.
  3. “Daqui a 12 a 18 meses, como o tamanho do seu time vai mudar?” — Segundo o WTI 2026 da Microsoft, 82% dos líderes pretendem usar agentes de IA para “expandir” a força de trabalho. Se a sua resposta for “não vai mudar”, ou o seu negócio não está crescendo, ou o desenho organizacional não está acompanhando os ganhos da engenharia orientada por especificações.

Não há resposta certa para essas três perguntas. Mas a direção das respostas importa mais do que as respostas em si.

Próximos passos

Este é o sexto artigo da série “A Transformação da Engenharia de Software na Era da IA”. Começamos com Conway (a organização determina a arquitetura), passamos por Team Topologies (como desenhar a organização), depois pelo deslocamento do gargalo (o gargalo está na validação, não na codificação), e hoje chegamos à engenharia orientada por especificações (usar documentação para orientar o comportamento da IA).

Na próxima edição (sétima), vamos explorar a infraestrutura subjacente que sustenta tudo isso: o protocolo MCP (Model Context Protocol). Por que esse protocolo open-source da Anthropic é chamado de “USB-C da IA”, por que OpenAI, Google e Microsoft todos o adotaram, e como ele viabiliza a interoperabilidade entre múltiplas ferramentas e agentes.

Quer colocar essa abordagem em prática na sua empresa?

Quando a condução por normas (spec-driven) entra em uma organização, os desafios reais geralmente se resumem a algumas questões concretas: como consolidar as regras centrais em arquivos como CLAUDE.md ou AGENTS.md, como adaptar o código legado às novas normas, como incorporar a conformidade regulatória e quais métricas usar para avaliar o projeto-piloto.

Atualmente, oferecemos três tipos de parceria:

  • Treinamento corporativo: Combinando com projetos reais da sua empresa, auxiliamos na elaboração da documentação de normas, no design de portões de verificação (CI gates), na integração de conformidade e na construção de mecanismos de governança.
  • Consultoria especializada: Focada em uma decisão específica, como “devemos escrever CLAUDE.md ou AGENTS.md primeiro?” ou na priorização de correções de conformidade para código legado.
  • Palestras para executivos e eventos do setor: abordando ferramentas de programação com IA, condução por normas, governança organizacional e Frontier Firms.

O artigo fornece um framework genérico. A implementação concreta, no entanto, ainda precisa ser redesenhada com base nos requisitos de conformidade da empresa, nos limites regulatórios, na maturidade de engenharia e nos fluxos de entrega existentes. Para colaborações, entre em contato via coach@iaiuse.com.

Leitura complementar: Metodologia da Placa de Sinalização v1.0 (Aprenda IA Lentamente 187), que apresenta de forma sistemática o framework de 7 etapas para a transformação de IA nas empresas.

Sobre esta série

“Transformação da Engenharia de Software na Era da IA” é uma série de pesquisa voltada para CIOs, CDOs, CTOs e líderes de transformação digital nos setores de telecomunicações, finanças, manufatura e e-commerce, com 18 artigos no total. O foco é discutir como ferramentas de programação com IA, engenharia orientada por especificações e governança organizacional impactam os fluxos de entrega de software, a estrutura organizacional e a maturidade de engenharia.

A série acompanha continuamente artigos acadêmicos, materiais de fornecedores e relatórios do setor. O acervo de pesquisa acumula mais de 200 referências, e as principais conclusões são classificadas por nível de evidência, distinguindo sempre que possível entre fatos verificados, alegações de fornecedores, observações do setor e inferências do autor.

Tenho quase 8 anos de experiência em consultoria para grandes empresas e análise de negócios, tendo atuado na IBM em projetos nos setores de telecomunicações, finanças, seguros e manufatura. Desde então, sigo na linha de frente do desenvolvimento de produtos para operadoras, produtos de internet e aplicações de IA, trabalhando com análise de requisitos, design de produto e implementação multifuncional.

Esta série de julgamentos sobre governança orientada por normas, governança organizacional e engenharia é baseada nessas práticas, combinadas com pesquisa pública e estudos de caso do setor para validação cruzada. O conteúdo relacionado a projetos específicos foi anonimizado; alguns cenários do setor são simulações de problemas típicos, com as respectivas referências listadas no final do artigo.

Este perfil é, na verdade, uma pequena equipe — eu e 1 a 2 colegas de longo prazo, cada um responsável por pesquisa de ferramentas de programação com IA, análise de casos de governança organizacional e coaching conversacional. A maioria dos projetos em que “acompanhamos empresas” foi entregue em conjunto por nós. Os limites de conformidade dos clientes e nomes de pessoas permanecem não divulgados; o anonimato é preservado para dar espaço a futuros colaboradores.

Referências (todas verificadas, com nível de evidência indicado por item)

  • CodeRabbit (2025.12). State of AI vs Human Code Generation Report. Código gerado por IA apresenta 1,7× mais problemas que o código humano (10,83 vs 6,45 problemas/PR), sendo 1,75× em lógica/correção, 1,64× em qualidade de código, 1,57× em segurança, 1,88× em tratamento de senhas e 2,74× em XSS. Nível de evidência: primário. Fonte: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263

  • The Register (2025.12.17). Cobertura do relatório completo da CodeRabbit: análise de 470 PRs de projetos open source, onde PRs com colaboração de IA apresentaram 10,83 problemas contra 6,45 de PRs exclusivamente humanos. Nível de evidência: secundário. Fonte: mesma URL acima

  • CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap” — 2026 marca a virada do foco em “velocidade de geração de código” para “qualidade e governança de código”. Nível de evidência: secundário. Fonte: https://tfir.io/ai-code-quality-2026-guardrails

  • New Relic (2026). The 2026 State of AI Coding Report. 78% das equipes relatam mais incidentes após colocar código de IA em produção; 62% dos líderes técnicos admitem que suas equipes “enviam código de IA com confiança, sem revisão”; 96% consideram observabilidade essencial. Nível de evidência: primário (relatório de fornecedor). Fonte: https://newrelic.com/resources/report/2026-state-of-ai-coding

  • Microsoft 2026 Work Trend Index Annual Report (2026.5.5). Pesquisa com 20.000 trabalhadores que usam IA, abrangendo 10 países; 82% dos líderes planejam expandir a força de trabalho com agentes de IA em 12 a 18 meses; 81% preveem integração moderada ou alta de agentes de IA; 24% já implementaram em nível empresarial; 49% das conversas com Copilot apoiam trabalho cognitivo; 58% dos usuários de IA afirmam ter feito “coisas que não conseguiriam há um ano”, número que sobe para 80% entre os Frontier Professionals. Nível de evidência: primário. Fonte: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf

  • ** Microsoft Retrospectiva do ano fiscal de 2026: da experimentação em IA à transformação de fronteira (2026.7.28).** A EY expandiu o uso do Microsoft 365 Copilot para 150.000 colaboradores, economizando 2,5 milhões de horas e aproximadamente US$ 250 milhões; depois ampliou para 400.000 pessoas no mundo todo, com 95% de aumento na velocidade de execução, queda de 37% nos custos de operação financeira e até 90% de redução em fluxos de trabalho manuais. A Atos implementou o Copilot para 56.000 empregados em 56 países, além de 19.000 agentes de IA, tudo sob um único plano de controle de identidade, segurança, compliance e governança. Nível de evidência: nível 1 (revisão oficial da Microsoft). Fonte: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Colaboração Estratégica entre Atos Group e Microsoft (2026.6.9). A Atos está implantando o Microsoft 365 E7 (Frontier Suite) para 56.000 funcionários em 56 países, além de 19.000 agentes de IA; unificando o plano de controle de Entra/Defender/Intune/Purview/Agent 365. Nível de evidência: primário (comunicado de imprensa conjunto). Fonte: 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 aberto em set/2025, evolução no 1º semestre de 2026). Gate de 5 estágios /speckit.constitution → /specify → /plan → /tasks → /implement, mais /clarify /analyze; agnóstico de modelo (funciona com Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code). Nível de evidência: primário. Fonte: https://github.com/github/spec-kit

  • AWS Kiro (lançado em jul/2025, evolução no 1º semestre de 2026). Fluxo de trabalho em três etapas: requisitos → design → tarefas; o spec dispara ações predefinidas dos agentes; sem spec, não inicia. Nível de evidência: primário. Fonte: https://kiro.dev/

  • OpenAI Codex — com AGENTS.md e Skills (2025-2026). Codex 2026.6: 5+ milhões de usuários ativos semanais, 20% deles não programadores; AGENTS.md e Skills formam um sistema de instruções combináveis. Nível de evidência: 1 (comunicado oficial da OpenAI). Fonte: https://developers.openai.com/codex/skills

  • Claude Code (Anthropic, 1º semestre de 2026). Usa CLAUDE.md, .claude/rules/ e um sistema de Skills; em fevereiro de 2026, entrou no mercado oficial da Anthropic; o repositório de Skills no GitHub tem 112 mil estrelas; em fevereiro de 2026, a rodada G revelou receita anualizada de US$ 2,5 bilhões. Nível de evidência: 1. Fonte: https://code.claude.com/docs/en/claude-directory

  • JetBrains AI Pulse Survey (2026.1). Pesquisa global com mais de 10.000 desenvolvedores profissionais, localizada em 8 idiomas; CSAT do Claude Code: 91% / NPS 54 (o mais alto do setor); adoção do Claude Code em ambientes de trabalho: 18% (crescimento de 6x em 9 meses, partindo de 3%), 24% na América do Norte; Copilot: 29% de adoção em ambientes de trabalho, mas com crescimento estagnado; Cursor: 18%. Nível de evidência: primário. Fonte: https://www.jetbrains.com/lp/tools/ai-tools/

  • Pragmatic Engineer Newsletter (2026.2). Pesquisa com 15.000 desenvolvedores; 46% elegeram o Claude Code como o “mais querido”, Cursor 19%, Copilot 9%. Nível de evidência: primário. Fonte: https://newsletter.pragmaticengineer.com/

  • Alibaba Qoder (ago/2025 → jul/2026). Lançado pela Alibaba em ago/2025; em 15/05/2026 o Qoder 1.0 foi atualizado para Autonomous Agent Development Workbench; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; em 28/05/2026, Cloud Agents (runtime de agentes gerenciados); em 21/07/2026, Qoder Security; em maio/2026, mais de 5 milhões de usuários globais; integração CLI com o DingTalk; em 20/05/2026, Tongyi Lingma foi renomeado para Qoder CN. Nível de evidência: primário. Fonte: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525.

  • vibecoding.app / thebcms.com / tfir.io (1º semestre de 2026). Comandos de cinco fases do Spec Kit, comparação e avaliação de ferramentas SDD, notação EARS. Nível de evidência: secundário (avaliação de terceiros). Fonte: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development

  • EU AI Act / Code of Practice (plena execução em 2/8/2026). O prazo de conformidade para sistemas de IA de alto risco é 2/8/2026; modelos GPAI existentes foram prorrogados até 2/8/2027; multas de até €35 milhões ou 7% da receita global; Art. 9-15 abrangem gestão de risco, governança de dados, transparência documental, supervisão humana, precisão e robustez. Nível de evidência: primário (regulamento + análise de conformidade secundária). Fonte: 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). 44% dos problemas têm como causa raiz a falta de contexto. Nível de evidência: secundário (relatório de fornecedor). Fonte: https://www.qodo.ai/reports/state-of-ai-code-quality/

Aprendendo AI Lentamente 001

O Futuro da Inteligência Artificial no Setor de Telecomunicações

Como CIOs e decisores de empresas de telecomunicações, financeiras, de manufatura e e-commerce, sabemos que a Inteligência Artificial (IA) está mudando a forma como operamos e tomamos decisões. Neste artigo, vamos explorar como a IA está sendo implementada em diferentes setores e como você pode aproveitar essas tecnologias para melhorar sua empresa.

O Papel da IA na Telecomunicação

A IA está sendo usada em diversas áreas da telecomunicação, incluindo:

  • Análise de Dados: A IA pode ajudar a analisar grandes conjuntos de dados para identificar padrões e tendências, melhorando a capacidade de previsão e tomada de decisões.
  • Gerenciamento de Redes: A IA pode ajudar a otimizar a gestão de redes, melhorando a eficiência e a capacidade de resposta.
  • Suporte ao Cliente: A IA pode ajudar a melhorar a experiência do cliente, fornecendo respostas personalizadas e rápidas.

Exemplo de Implementação

A empresa de telecomunicações AT&T está usando a IA para melhorar a experiência do cliente. Eles estão usando a tecnologia para fornecer respostas personalizadas e rápidas, ajudando a reduzir a quantidade de chamadas para o suporte ao cliente.

O Papel da IA no Setor Financeiro

A IA está sendo usada em diversas áreas do setor financeiro, incluindo:

  • Análise de Risco: A IA pode ajudar a analisar grandes conjuntos de dados para identificar padrões de risco e melhorar a capacidade de previsão.
  • Gerenciamento de Ativos: A IA pode ajudar a otimizar a gestão de ativos, melhorando a eficiência e a capacidade de resposta.
  • Suporte ao Cliente: A IA pode ajudar a melhorar a experiência do cliente, fornecendo respostas personalizadas e rápidas.

Exemplo de Implementação

A empresa de banco NTT está usando a IA para melhorar a experiência do cliente. Eles estão usando a tecnologia para fornecer respostas personalizadas e rápidas, ajudando a reduzir a quantidade de chamadas para o suporte ao cliente.

O Papel da IA no Setor de Manufatura

A IA está sendo usada em diversas áreas do setor de manufatura, incluindo:

  • Análise de Dados: A IA pode ajudar a analisar grandes conjuntos de dados para identificar padrões e tendências, melhorando a capacidade de previsão e tomada de decisões.
  • Gerenciamento de Produção: A IA pode ajudar a otimizar a gestão de produção, melhorando a eficiência e a capacidade de resposta.
  • Suporte ao Cliente: A IA pode ajudar a melhorar a experiência do cliente, fornecendo respostas personalizadas e rápidas.

Exemplo de Implementação

A empresa de manufatura KDDI está usando a IA para melhorar a experiência do cliente. Eles estão usando a tecnologia para fornecer respostas personalizadas e rápidas, ajudando a reduzir a quantidade de chamadas para o suporte ao cliente.

O Papel da IA no Setor de E-commerce

A IA está sendo usada em diversas áreas do setor de e-commerce, incluindo:

  • Análise de Dados: A IA pode ajudar a analisar grandes conjuntos de dados para identificar padrões e tendências, melhorando a capacidade de previsão e tomada de decisões.
  • Gerenciamento de Stock: A IA pode ajudar a otimizar a gestão de stock, melhorando a eficiência e a capacidade de resposta.
  • Suporte ao Cliente: A IA pode ajudar a melhorar a experiência do cliente, fornecendo respostas personalizadas e rápidas.

Exemplo de Implementação

A empresa de e-commerce ByteDance está usando a IA para melhorar a experiência do cliente. Eles estão usando a tecnologia para fornecer respostas personalizadas e rápidas, ajudando a reduzir a quantidade de chamadas para o suporte ao cliente.

Conclusão

A IA está mudando a forma como operamos e tomamos decisões em diferentes setores. É importante entender como a IA está sendo implementada em sua empresa e como você pode aproveitar essas tecnologias para melhorar sua empresa.

]]> IA não enxerga suas regras: 1,7× mais bugs e 2,74× mais falhas XSS. Spec Kit, Kiro, Codex e Claude Code convergem em 2026 H1 — regras escritas em CLAUDE.md. 【Spec-Driven】Spec-Driven Development — Att skriva specifikationer är den högsta ROI-åtgärden inom ingenjörskonst i AI-eran. Förändringen av mjukvaruutveckling i AI-eran — Lär dig AI långsamt 177 https://iaiuse.com/sv/posts/spec-driven-development-att-skriva-specar-%C3%A4r-den-h%C3%B6gsta-ROI-%C3%A5tg%C3%A4rden-i-AI-eran 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z Ditt största misstag är inte att du inte köpt verktygen – det är att du inte skrivit CLAUDE.md

En CIO på en affärsbank klagade till mig: AI-verktygen är inköpta, modellerna är driftsatta, personalen är utbildad – och ändå har leveranstiden knappt rört sig under hela första halvåret 2026. Chefen för kärnsystemgruppen var ännu mer rakt på sak: “AI-genererad kod fungerar, men vi måste skriva om allt varje gång – den förstår inte våra interna regler, inte tillsynskraven, inte hur man integrerar med det 30 år gamla legacy-systemet.”

Datakällor i texten: CodeRabbit 2025.12 / New Relic 2026-rapporten, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms-meddelandet, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. Fallbeskrivningarna är sammanfattningar av representativa scenarier och avser inte specifika företag.

Problemet är inte att AI:n inte är tillräckligt stark – det är att ni inte har skrivit ner reglerna. CodeRabbit:s analys av 470 open source-PR:er i december 2025 gav en uppsättning siffror som citerats brett: AI-samarbetande PR:er innehåller i genomsnitt 10,83 problem, medan rent manuella PR:er ligger på 6,45 – 1,7 gånger, alltså 70 % fler buggar än manuellt arbete. Fram till 2026 har berättelsen inte vänt: New Relic fann i 2026 State of AI Coding Report att 78 % av teamen rapporterade fler incidenter efter att AI-kod gått i produktion, och 62 % av tech-ledarna medgav att deras team “självsäkert skickar iväg AI-kod utan att granska rad för rad” (New Relic officiella rapport 2026, 0,866 score, primärkälla). Båda dataserierna säger samma sak – AI:n saknar inte kapacitet, den saknar kontext.

I augusti 2026 måste alla berättelser om “accelererad AI-transformation” läsas mot en gemensam jämförelsegrund:

LägerFramsteg (H1 2026)Motexempel (H1 2026)
EYMicrosoft 365 Copilot rullas ut till 150 000 anställda, vilket sparar 2,5 miljoner timmar / 250 miljoner USD; utökas till 400 000 globala medarbetareErkänner samtidigt att 95 % snabbare processer och 37 % lägre finansiella driftkostnader förutsätter “styrning först”
AtosDriftsatt i 54 länder / 56 000 anställda; kör samtidigt 19 000 AI-agenter med en enhetlig kontrollplan för identitet/säkerhet/efterlevnad/styrningHåller hårt i principen “först lansera Agent 365:s styrningsförmåga, därefter skala upp”
Microsoft själva2026 Work Trend Index: 82 % av ledarna planerar att utöka arbetsstyrkan med AI-agenter inom 12–18 månaderErkänner samtidigt att “organisationens förändringstakt släpar efter individens användning” – detta är den centrala motsättningen i Frontier Firm-konceptet

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

Dessa två jämförelser visar en sak: utan styrning är skalning detsamma som att multiplicera risken med N. EY/Atos/Microsofts “snabbhet” handlar inte om att modellerna är snabba – det handlar om att organisationen först har svarat på frågan “hur ska vi använda AI?”. Detta är bakgrunden till att Spec-Driven Development (SDD) verkligen blev mainstream under H1 2026 – inte för att ingenjörer föredrar dokumentation, utan för att man inte längre överlever i en miljö med 19 000 agenter utan att skriva specifikationer.

Den här artikeln redogör för tre saker: 1) varför defekter i AI-kod är minst 1,7 gånger allvarligare än mänskligt skriven kod; 2) hur GitHub, AWS, OpenAI, Anthropic och Alibaba under H1 2026 alla rörde sig mot samma paradigm – att styra AI-beteende med dokumentation; 3) varför specifikationsdriven utveckling är en organisatorisk förmåga, inte ett verktygsval – och de tre implementeringsfaserna under H1 2026.

AI-kod vs mänsklig kod: fel fördelning (470 öppen källkod PR-analys) CodeRabbit 2025.12 rapport | alla siffror är AI/mänskliga multiplar (baslinje 1.0)

Stapellängd = AI-fel är mänskliga multiplar; baslinje 1.0× = mänsklig nivå

Baslinje 1.0×

Totalt antal problem

1.7×
AI 10.83 vs mänsklig 6.45 / PR

Logik/korrekt fel

1.75×

Kodkvalitet/underhållbarhet

1.64×

Säkerhetsupptäckt (sammanfattning)

1.57×

Olämplig hantering av lösenord

1.88×

XSS-sårbarhet

2.74×
↑ Högst

Ingen standardiserad AI-kod, alla dimensioner högre än mänsklig
Finans/tel = efterlevnad av kontroll, lösenordshantering, känsliga fältkryptering, AI ser inte allt

1. AI-defekter handlar inte om modellen – det handlar om kontexten

I CodeRabbits rapport finns en mening som citerats om och om igen: “AI saknar lokal affärslogik: modellen drar statistiska slutsatser om kodmönster snarare än att förstå semantik. Utan strikta begränsningar missar de systemregler som seniora ingenjörer har internaliserat.”

Den meningen förklarar varför CodeRabbits egen AI-programmeringsplattform (ett företag som specialiserat sig på AI-driven kodgranskning) såg dessa siffror tidigare än andra – de granskar tusentals pull requests varje dag och ser dagligen hur AI-genererad kod faktiskt ser ut. Det “viktigaste” fyndet är inte totalsiffrorna, utan fördelningen:

  • Logik/korrekthet +75 %: affärslogikfel, beroendefel, kontrollflödesfel, konfigurationsfel – den här typen av problem syns inte alltid i tester, men orsakar incidenter i produktion.
  • Kodkvalitet +64 %: inkonsekvent namngivning, otydlig struktur, avvikelser från projektmönster – detta är “den största differenskategorin”. En senior ingenjör ser direkt att “det här är inte så vi skriver kod här”.
  • Säkerhet +57 % (XSS högst med 2,74×): felaktig lösenordshantering (1,88×), osäkra objektreferenser (1,91×), läckage av känslig information, osäker deserialisering (1,82×) – inom finansbranschen handlar det inte om “fungerar det”, utan “får vi släppa det”.

Problemet är inte att AI:n inte är tillräckligt stark. Det är att den inte ser.

Tillbaka till CIO:ns verkliga smärtpunkt – tre konkreta fel som AI gör i finansiella kärnsystem:

För det första: AI:n ser inte 30 år av avstämningslogik. Bankens riskregler ligger lagrade i kärnsystemets stored procedures – skrivna för 30 år sedan, ingen minns dem längre. Den AI-genererade koden ser logiskt korrekt ut, men i produktionsmiljön triggar den en avstämningskontroll som ingen längre kommer ihåg, och hela transaktionsbatchen misslyckas.

För det andra: AI:n ser inte regelefterlevnaden. Lösenord måste gå via nyckelhanteringssystem, känsliga fält måste krypteras i lagring, loggar får inte skriva ut kundinformation – detta är hårda regulatoriska krav, nedskrivna i interna policies. AI:n känner inte till dem. Koden den skriver fungerar, men klarar inte compliance-granskningen.

För det tredje: AI:n ser inte din tekniska skuld. Det 30 år gamla värdssystemet använder ett eget interface-protokoll, och dokumentationen är sedan länge borta. AI:n skriver kod enligt generell RESTful-standard, och när den väl är i produktion visar det sig att gränssnitten inte matchar – två veckors omarbetning.

Tillbaka till New Relics andra siffror: 62 % av teamen “skickar iväg AI-kod med självförtroende utan granskning”, och 78 % rapporterar fler incidenter efter driftsättning. Sätter man ihop dessa två siffror säger de i praktiken: Defektfrekvensen i AI-kod är inte problemet i sig – “jag vet inte vad som är fel i AI-koden” är problemet.

Typiskt scenario: En aktiebank inför AI-stödd utveckling av riskkontrollmodulen i sitt kärnsystem. Inom tre månader ökar returandelen vid regelefterlevnadsgranskning markant – huvudproblemen är interna regler kring lösenordshantering, kryptering av känsliga fält och loggkompatibilitet. Reglerna finns dokumenterade internt, men AI:n ser dem inte. När teamet senare skrev in kärnreglerna i CLAUDE.md sjönk returandelen tydligt.

2. De fem plattformarnas H1 2026: Samma mål, olika vägar – “regelstyrt” blir normen

I juli 2025 lanserade GitHub Spec Kit, och i början av 2026 fyllde AWS Kiro, OpenAI Codex och Anthropic Claude Code samtliga luckor. I maj 2026 skrev Alibaba Qoder in “Spec-Driven Workflow” i sin produktpositionering. De fem plattformarna har under H1 2026 nått samma paradigm – att använda dokumentation för att styra AI:s beteende. Det är ingen enskild uppfinnare bakom, utan branschens kollektiva svar på “AI-kodkvalitetskrisen”.

De fem stora plattformarnas standarddrivna väg (2025-2026 H1) GitHub Spec Kit Öppen källkod 2025.9 constitution.md Multistegskontroll: constitution → specify → plan → tasks → implement Modellagnostisk, kan anslutas till flera agenter Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md Trestegsarbetsflöde: Krav → Design → Uppgift Specdriven IDE-arbetsflöde Hook-utlöst automatisk agent Förinställda efterlevnads-/revisionshookar Kräver spec för att starta OpenAI Codex 2025-2026 AGENTS.md + Färdighetssystem Sammansättlig kommandosamling Teamnivådelad konfiguration 5M+ veckovisa aktiva användare (2026.6) Icke-utvecklare utgör 20% Från programmering till allmän agent Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + Färdigheter（officiell marknad 2026.2） + MCP ekosystem CSAT 91% / NPS 54 $2.5B ARR（2026.2） GitHub 11.2 tusen stjärnor Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Quest Mode självständig körning + Expert Mode team + RepoWiki sammanhang 5M+ globala användare（2026.5） 2026.7.21 Qoder Security DingTalk CLI har anslutits Gemensamt paradigm：AI samarbetsstandard Låt alla människor och alla AI-agenter arbeta med samma standard

Låt oss gå igenom varje plattforms senaste drag under H1 2026:

GitHub Spec Kit: referensimplementation med femstegs grindar. Open source-släppt i september 2025, och vid H1 2026 hade det blivit branschens referensimplementation. 5 kärnkommandon + 2 kompletterande: /speckit.constitution (icke förhandlingsbara principer), /speckit.specify (vad som ska göras och varför), /speckit.plan (hur ändringen görs), /speckit.tasks (uppdelning i uppgifter), /speckit.implement (exekvering), plus /clarify och /analyze. Den centrala designprincipen är modellagnostisk – samma spec/plan/tasks-filer är inte bundna till någon specifik exekveringsagent; Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf och Qwen Code kan alla ansluta. Detta har gjort det till ett “organisationsövergripande SDD-protokoll” snarare än en GitHub-specifik produkt (vibecoding.app-utvärdering 2026.6, 0.816 score, sekundärkälla).

AWS Kiro: Inbäddad specifikationsdriven utveckling direkt i IDE:n. Lanserades i juli 2025 och utvecklades under första halvåret 2026 till en komplett Agent IDE. Arbetsflödet är uppdelat i tre faser: krav → design → uppgift. Skillnaden mot Spec Kit ligger i “krokarna” – Kiro:s spec-filer kan utlösa fördefinierade agentåtgärder, vilket gör att steg som kräver externa system (efterlevnad, granskning, driftsättning) kan förberedas direkt i arbetsflödet. Vill du tvinga teamet att skriva specifikationer? Då är Kiro rätt val – för utan en spec går Kiro inte att starta (AWS Kiro officiell dokumentation 2025.7; Kiro.dev-dokumentation 2026).

OpenAI Codex: AGENTS.md + komponerbara Skills. Under 2025–2026 har AGENTS.md flyttats till ekosystemets centrum. Skills är den viktigaste utökningen under H1 2026: arbetsmoment som “läsa Excel-filer”, “generera SQL” och “köra datamigrering” förmonteras och kan anropas som LEGO-bitarna. Codex passerade 5 miljoner veckoaktiva användare i juni 2026, varav 20 % är icke-utvecklare – en signal som ofta förbises: styrning via specifikationer är inte längre enbart en fråga för ingenjörsteamen, utan för alla. Produkt, drift och riskhantering skriver nu alla AGENTS.md (OpenAI 2026.6.2 announcement; thebcms.com review 2026, 0.801 score).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic kallar sina projektinstruktionsdokument för CLAUDE.md (som gick in på den officiella marknaden i februari 2026), .claude/rules/ (regler organiserade per katalog) och Skills (delbara arbetsflöden). Claude Code var det verktyg med högst utvecklarnöjdhet under första halvåret 2026 – JetBrains 2026.1-undersökning rapporterar CSAT 91 % och NPS 54, vilket bekräftas av två oberoende studier (Pragmatic Engineer 2026.2). Det är den högsta poängen hittills bland AI-kodningsverktyg i branschen (uvik.net 2026.5, 0,956 score, aggregering av primärkällor). Claude Code gick från noll till 2,5 miljarder USD i årlig återkommande intäkt på nio månader (enligt Anthropics Series G, 2026.2) och GitHub-repot för Skills har 112 000 stjärnor – utvecklarna har röstat med fötterna, vilket visar det verkliga värdet av regelstyrd utveckling.

Alibaba Qoder: drivet av Kinas regleringslandskap. Lanseringen skedde i augusti 2025, och den 15 maj 2026 uppgraderades verktyget till version 1.0 – från att formellt ha varit en “AI-IDE” till att bli en “Autonomous Agent Development Workbench”. Spec-Driven Workflow introducerades tillsammans med Quest Mode (autonoma flerfiluppgifter), Expert Mode (parallellt arbete i expertteam) och RepoWiki (kunskapsgraf över kodbasen). Den 28 maj 2026 lanserades Cloud Agents (en fullt hanterad agentkörningsmiljö), den 21 juli samma år kom Qoder Security (funktioner för regelefterlevnad och säkerhet), och samma månad släpptes även mobilversionen (Android/iOS/HarmonyOS). I maj 2026 passerade verktyget fem miljoner globala användare, och DingTalk CLI listar det som en av de stödda agentexekveringsmiljöerna (Yahoo Finance 2025; Alibaba Cloud officiell 2026; Baidu Baike 2026.7).

Gemensam paradigm: Att skriva ner “hur vi samarbetar med AI” i en explicit dokumentation, lägga den i repot, och låta alla människor och alla AI-agenter arbeta mot samma specifikation. De fem plattformarnas implementationer skiljer sig åt (filnamn/antal faser/hook-mekanismer), men målet är identiskt.

Varför händer detta koncentrerat under H1 2026? För att tröskeln för AI-kapacitet redan är passerad – Claude Code autonoma agenter, Codex multi-agent-parallellism, Cursor multi-fil-refaktorering. AI är inte längre ett “autocomplete-verktyg”, det är en “kollega”. Den onboarding-dokumentation du skulle ge en ny kollega måste också kunna ges till AI.

Tre: Specifikationsdrivet är en organisatorisk förmåga, inte ett verktygsval

Detta är den viktigaste punkten för beslutsfattare. Specifikationsdrivet handlar inte om att välja verktyg, det handlar om att definiera “hur vår organisation samarbetar med AI”. Om du väljer GitHub Spec Kit eller Claude Code spelar ingen roll. Det som spelar roll är om du har skrivit ner specifikationen i dokumentation, lagt den i repot, och fått alla människor och AI att arbeta mot den.

Utan detta kommer de bästa verktygen bara att låta teamet bygga upp mer teknisk skuld i snabbare takt.

Om vi sätter detta i perspektivet av storskalig driftsättning under första halvåret 2026, blir bevisläget ännu starkare. I Microsofts FY26-retrospektiv från juli 2026 lyfts EY och Atos fram som “Frontier Firm”-mallar – inte för att modellerna är nya, utan för att båda dessa företag först besvarade frågan “hur använder vi AI?”:

EY: Styrning först, skalning sedan. Under 2024–2025 rullade EY ut Microsoft 365 Copilot till 150 000 medarbetare, vilket sparade 2,5 miljoner timmar och cirka 250 miljoner USD. Förutsättningen var att AI-styrningsramverket byggdes först: EY använde Power Platform, Copilot Studio, Azure, Foundry och Fabric för att skapa en enhetlig verktygskedja, där policy, regelefterlevnad och granskning samlades i samma grundplattform. Först därefter kunde man uppnå 95 % snabbare processer, 37 % lägre finansiella driftkostnader och upp till 90 % minskning av manuella arbetsflöden. EY:s vice vd uttryckte det rakt på sak under AI Tour 2026: “Vi rullade inte ut AI först och la till styrning i efterhand – vi byggde styrningen först och rullade sedan ut AI.”

Atos: Ett enhetligt kontrollgränssnitt för 19 000 agenter. Atos är bland de första organisationerna i världen att driftsätta Microsoft 365 E7 (Frontier Suite) och har rullat ut Copilot till 56 000 anställda i 54 länder. Samtidigt kör de 19 000 AI-agenter – från intern IT och affärsenheter till kundprojekt, allt byggt med Foundry och Copilot Studio. Nyckeln till Atos framgång är “ett kontrollgränssnitt”: Entra (identitet) + Defender (säkerhet) + Intune (enheter) + Purview (efterlevnad) + Agent 365 (agentstyrning), fem delar som hålls samman. Denna sammanhållna struktur motsvarar inom finanssektorn en kombination av “dengbao (krav på skydd av informationssystem), utvärdering av dataöverföring över gränser, algoritmregistrering, revision och modellstyrning” – det är en styrningsarkitektur, inte bara ett AI-verktyg.

Microsofts eget “organisationsförändringsparadox”. I 2026 års Work Trend Index-rapport erkänner Microsoft själv ett faktum: “Organisationernas förändringstakt halkar efter individens användning.” Av de 20 000 AI-användare som ingick i undersökningen uppger 82 % av ledarna att de planerar att utöka arbetsstyrkan med AI-agenter inom 12–18 månader, men bara 24 % har redan genomfört en företagsomfattande implementering. 81 % av ledarna förväntar sig att AI-agenter kommer att integreras i AI-strategin i måttlig till hög grad – men även här är det bara 24 % som redan gjort det. Det innebär att de flesta företag har ett gap på 12–18 månader mellan “förberedelse” och “genomförande”. Frågan är hur detta gap ska överbryggas – och här är regelstyrning den bärande pelaren.

Källa: Microsoft FY26 retrospective 2026-07-28; Microsoft 2026 Work Trend Index Annual Report 2026-05-05 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, PDF primärkälla); Futurum Group 2026-01-26 analys (sekundärkälla).

Insikt ett: Att investera i styrning ger hög ROI.

CodeRabbit ger en tydlig grund för ROI-beräkning: AI-kodproblem uppstår cirka 1,7 gånger oftare, och säkerhetsbrister minskar med 2,74 gånger. Det innebär:

  • Mindre omarbete (inom finansbranschen kan en enda regelefterlevnadsgranskning ta 2–4 veckor)
  • Färre säkerhetsincidenter (ett dataläckage innebär både regulatoriska böter och ryktesförluster)
  • Lägre underhållskostnader (en teknisk skuldminskning på 40 % är en vanlig siffra)

Att skriva en CLAUDE.md/AGENTS.md-projektspecifikation är den enskilt mest ROI-effektiva ingenjörsåtgärden i AI-eran. EY:s fall ger en verklig omvandling — 150 000 personer med Copilot, besparingar på 250 miljoner dollar. Notera att EY inte sparade pengar för att “verktyget är kraftfullt”, utan för att “specifikationen realiserade verktygets värde”.

Insikt två: Skriv in specifikationen i organisationens processer, förlita dig inte på individer.

Om specifikationen bara finns i huvudet på en senior ingenjör, försvinner den när personen slutar. Den måste förankras i:

  • Repositoriedokumentation (AGENTS.md / CLAUDE.md / constitution.md)
  • CI-grindar (automatisk kontroll av specifikationsefterlevnad)
  • Delade teamkonfigurationer (Skills-systemet gör att hela teamet kan använda den)

Låt styrning bli en organisatorisk tillgång, inte en individuell färdighet. Detta är särskilt viktigt inom finansbranschen – era regelefterlevnadskrav, säkerhetsregler och affärsregler är organisatoriska tillgångar, inte någon engineers “erfarenhet”. Atos 19 000 agenter kan köra i 54 länder eftersom styrningen inte handlar om att “någon förstår”, utan om att “systemet tvingar fram”.

Insikt tre: Grindar viktigare än hastighet.

GitHub Spec Kits femstegsgrind (constitution → specify → plan → tasks → implement), Claude Codes “skriv inte kod innan tester misslyckats” och Kiros “kan inte starta utan spec” gör alla samma sak: de lägger på en “broms” mellan AI och slutresultatet. Varje steg har granskningsbara artefakter (spec.md, plan.md, tasks.md) som kan avvisas eller ändras innan kodgenerering.

Ju mer autonom AI, desto mer grindar behövs. Change Advisory Board (Change Advisory Board (CAB)), algoritmregistrering och ISO 27001 + MSB 系统性安全方法 (kinesisk säkerhetsklassning för informationssystem) inom finansbranschen handlar i grunden om att lägga till grindar före produktion. AI-kod behöver liknande grindar, bara i annan form. De 62 % av teamen i New Relics 2026-rapport som “självsäkert släpper utan granskning” betalar nu för den självsäkerheten med högre incidentfrekvens (78 %).

Finansbranschens standardisering i tre faser Första fasen：inventering av regler 2-4 veckor｜tar mest tid，ROI högst Kravlista för efterlevnad（kybersecurity/utlandsöverföring/registrering） Säkerhetsregler（lösenord/kryptering/loggning） Riskkontroll/transaktion/faktureringsregler Äldre gränssnitt/versionsbegränsningar Leverantörsstyrning Regler för rensning Strukturerad dokumentation Lagringsplats för lagring AI-inläsning CLAUDE.md / AGENTS.md constitution.md Delad kompetens Processdesign Hierarkiska regler Regler för lagring AI-inläsning Institutionaliserad Organisatorisk förmåga Automatisk granskning Teamdelad konfiguration Regelbunden uppdateringsmekanism Mätning (Defektfrekvens/efterlevnadskompatibilitet) Ombudsstyrning (Agent 365 Nivå 1) Standardisering blir en organisations tillgång Oberoende av enskilda individer

Den första fasen tar mest tid, men ger högst ROI
De flesta finansiella organisationers regler är utspridda i dokument/e-post/mänskliga hjärnor, den första sammanställningen tar 3-8 veckor

Fyra. Verklig implementering i tre faser – H1 2026

Med finansbranschen som exempel – de tre faserna går att överföra till andra hårt reglerade branscher. EY:s och Atos praktik under H1 2026 motsvarar precis dessa tre faser.

Fas ett: Inventering av regler (2–4 veckor).

Detta är den mest tidskrävande fasen, men också den med högst ROI. Hitta alla regler som ligger utspridda på olika håll:

  • Efterlevnadskrav: För finansbranschen är miniminivån = Multi-Level Protection Scheme nivå 3 (kinesisk säkerhetsklassificering) + bedömning av gränsöverskridande dataöverföring + algoritmregistrering (saknas en enda – skippa AI-satsningen). Därutöver finns regler för regulatorisk rapportering, kundintegritetsskydd, begränsningar för gränsöverskridande dataflöden, samt vilka data som över huvud taget får exponeras för AI
  • Säkerhetsregler: Lösenordshantering, krypteringsstandarder, hantering av känsliga fält, loggkrav
  • Affärsregler: Riskgränsvärden, skadevillkor, transaktionsbegränsningar, faktureringslogik
  • Tekniska begränsningar: Äldre systemgränssnitt, databasnamnkonventioner, versionskrav på ramverk
  • Leverantörsstyrning: Hur man i avtal kräver att leverantörer följer våra standarder, och hur man reviderar leverantörernas AI-användning

Typiskt scenario: Ett värdepappersbolag upptäckte under inventeringsfasen att reglerna var utspridda över ett stort antal Word-dokument, JIRA-wikis, personliga e-postmeddelanden och Excel-ark – först efter sammanställningen fick de en strukturerad regellista. Atos metod är mer systematisk – de delar helt enkelt in reglerna i fem kategorier: “regelefterlevnad, säkerhet, verksamhet, teknik och leverantörer”, med en separat styrningsworkflow för varje kategori, alla anslutna till Agent 365:s kontrollplan.

Detta är ingen teknisk uppgift, utan en organisatorisk sådan – du måste samla efterlevnads-, säkerhets- och verksamhetsavdelningarna för att tillsammans skriva ner de regler som alla är överens om. Första gången detta görs tar det vanligtvis 3–8 veckor för finansiella organisationer – men det är en permanent organisatorisk tillgång.

Fas två: Lägga in i repositoryt (1–2 veckor).

Skriv ner reglerna från fas ett som dokument och lägg dem i repositoryt. GitHub Spec Kit använder constitution.md, Claude Code använder CLAUDE.md, OpenAI Codex använder AGENTS.md, och Alibaba Qoder använder Spec Workflow. Filnamnen skiljer sig åt, men målet är detsamma – att AI:n laddar dem så fort den öppnar repositoryt.

Strukturförslag (vanligaste formen under 2026 H1):

  • Projektöversikt: Vad systemet gör och vem det betjänar
  • Icke förhandlingsbara principer: Säkerhetslinjer, regelefterlevnadslinjer, affärskritiska linjer
  • Teknisk stack och begränsningar: Ramverk, databas, gränssnittsstandarder
  • Kodstandard: Namnkonventioner, katalogstruktur, minsta testtäckningskrav (ingen obligatorisk TDD-takt — specificera testtäckning, obligatoriska testvägar och förbjudna vägar; TDD är en organisatorisk valfrihet, inte ett hårt krav)
  • Affärsregler: Riskkontrolllogik, transaktionsregler, faktureringsregler
  • Regelefterlevnad: Nivåskyddsbedömning (等保 – kinesisk säkerhetsklassificering), dataöverföring över gränserna, tillsynsrapportering, AI-genererade algoritmer som kan kräva registrering
  • AI-användningsriktlinjer: Var AI får användas, var mänsklig granskning är obligatorisk, regler för dataöverföring över gränserna
  • Leverantörsstyrning: Avtalsvillkor, revisionsmekanismer, ansvarsfördelning

Bilaga: CLAUDE.md – finansversionens skelett (ca 200 rader, direkt fork-anpassningsbart)

Nedan följer ett CLAUDE.md-skelett för kärnsystemsmigrering i en aktiebank, strukturerat i ordningen “icke förhandlingsbara principer → regelefterlevnad → AI-användningsriktlinjer → affärsregler → tekniska begränsningar”. Ni behöver inte börja från noll — fyll bara i era specifika regler i de tomma fälten.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
# CLAUDE.md — <systemnamn> AI-samarbetsstandarder

> Tillämpningsområde: <systemnamn> v<version>, alla AI-agenter (Claude Code / Cursor / Copilot / Codex)
> som arbetar i detta repo måste följa dessa standarder. Filen underhålls av <styrningskommitté>, kvartalsvis granskning.
> Senast uppdaterad: YYYY-MM-DD

## 1. Projektöversikt
- **Affärspositionering**: kärnsystemets namn / betjänade kundsegment / huvudsakliga transaktionstyper
- **Kritisk kedja**: transaktion → riskkontroll → avveckling → avstämning → rapportering
- **Otillgänglighetsfönster**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (inga ändringar tillåtna)
- **Kärnberoenden**: uppströms <system>, nedströms <system>, plattform för regelefterlevnadsrapportering

## 2. Icke-förhandlingsbara principer (röda linjer – överträdelse = merge avvisas)

### 2.1 Säkerhets-röda linjer
- Lösenord, nycklar och tokens hanteras uteslutande via KMS (Key Management Service) – **hårdkodning förbjuden**, **utskrift i loggar förbjuden**
- Känsliga kundfält (ID-nummer / kortnummer / CVV / mobiltelefonnummer) **måste krypterast vid lagring**; klartext i databasen är förbjudet
- Loggar får aldrig innehålla: fullständigt ID-nummer, fullständigt kortnummer, klartextlösenord, kombination kundnamn + mobiltelefonnummer
- Externa API-anrop måste gå via API-gateway; direktanslutning är förbjuden

### 2.2 Compliance-röda linjer
- AI-genererad kod som hanterar kunddata måste i PR-beskrivningen märkas med "dataåtkomst: <fält>"
- Gränsöverskridande dataöverföring är förbjuden; **all dataöverföring ut ur landet måste gå via bedömning av gränsöverskridande dataöverföring** (kontakta compliance)
- Algoritmiska beslut (kredit / försäkringsprissättning / bedrägeribekämpning) måste ha en kvarstående manuell granskningsingång
- Modelländringar kräver algoritmregistrering; registreringsnumret måste citeras i PR-beskrivningen

### 2.3 Affärs-röda linjer
- Ändringar av riskkontrolltrösklar kräver dubbelsignering av riskansvarig + affärsansvarig
- Operationer som rör kundmedel måste ha idempotensdesign + rollback vid fel
- Transaktionsgränser, taxor och produktparametrar hanteras via parametermhanteringsplattformen; ingen hårdkodning i koden

## 3. Teknikstack och begränsningar
- **Språk**: Java 17 (kärna) / Kotlin (nya moduler) / SQL (databas)
- **Ramverk**: Spring Boot 3.x + Spring Cloud Alibaba
- **Databas**: OceanBase 4.x (MySQL-kompatibelt läge), **främmande nycklar förbjudna**
- **Gränssnittsstandarder**: gRPC internt; OpenAPI 3.0 för externa gränssnitt; RESTful endast för administrationsgränssnitt
- **Namnkonventioner**: Java-klasser PascalCase, metoder camelCase, konstanter UPPER_SNAKE; tabellnamn `t_<affärsdomän>_<entitet>`; index `idx_<tabell>_<fält>_<ordning>`
- **Paketstruktur**: `com.<företag>.<affärsdomän>.<subdomän>.<lager>` (t.ex. `com.bank.pay.tx.core.service`)

## 4. Kodstandarder
- **Lägsta testtäckning**: kritisk kedja ≥ 80 %, verktygsklasser ≥ 60 %, ny kod i PR måste innehålla tester
- **Obligatoriska testvägar**: alla controllers måste ha integrationstester (inklusive felvägar); alla enum-grenar måste ha enhetstester
- **Förbjudna vägar**: ändring av katalogen `<historisk arvsmodul>` är förbjuden – bygg först ett adapterlager
- **Beroendehantering**: nya tredjepartsberoenden kräver SCA-skanning + säkerhetsgodkännande

## 5. Affärsregler (per domän)
### 5.1 Transaktioner
- Gräns per transaktion: <belopp>; dagsgräns: <belopp>; överskridande kräver manuellt godkännande
- Transaktionstidsfönster: <HH:MM> ~ <HH:MM>
- Duplikattransaktionsbedömning: inom <tidsfönster> med samma <fält> = duplikat

### 5.2 Riskkontroll
- Prioritetsordning för svartlistmatchning: intern svartlista → regulatorisk nedstigningslista → judiciell frysning
- Utdata-tröskelvärde för bedrägerimodell: <poäng>; överstigande kräver manuell andra granskning

### 5.3 Fakturering
- Taxändringar måste ha versionsnummer + ikraftträdandedatum
- Historiska order beräknas enligt den taxa som gällde vid ikraftträdandet, utan retroaktivitet

## 6. Compliancekrav
- MLPS nivå 3 (等保三级 – kinesisk säkerhetsklassificering): <utvärderingsorgan>, <nästa utvärderingsdatum>
- Bedömning av gränsöverskridande dataöverföring: tillämpningsområde (endast gränsöverskridande affärsmoduler)
- Algoritmregistrering: tillämpningsområde (kredit / försäkringsprissättning och andra nyckelalgoritmer), registreringsnr `<registreringsnr>`
- Regulatorisk rapportering: fältmappningstabell för CBIRC / Folkbanken i Kina finns i `<sökväg>`

## 7. AI-användningsstandarder
- **Scenarier där AI är tillåten**: CRUD-mallar, generering av enhetstester, dokumentutkast, SQL-optimeringsförslag
- **Scenarier som kräver manuell granskning**: riskkontrollogik, faktureringsregler, behörighetskontroll, kryptering/dekryptering, gränsöverskridande data
- **Scenarier där AI ensam är förbjuden**: Change Advisory Board (CAB)-godkännandematerial, körning av produktionsändringar, katastrofhantering
- **Regler för dataöverföring ut ur landet**: träningsdata / prompts / utdataloggar lämnar aldrig landet; lokalt distribuerade versioner (<leverantör>) prioriteras
- **Granskningskrav**: all AI-genererad kod måste i PR-beskrivningen märkas med "AI-assistans: <verktygsnamn>"

## 8. Leverantörsstyrning
- **Leverantörskvalificering**: tillhandahållande av SOC 2 / ISO 27001-rapport krävs; AI-modeller måste ha en model card
- **Avtalsvillkor**: dataäganderätt, modellförklarbarhet, exitklausul, granskningsrätt
- **Granskningsmekanism**: kvartalsvis AI-användningsrevision av leverantörer; högriskleverantörer månatligen

## 9. Styrning och uppdateringar
- **Ägare**: <styrningskommitté> (compliance + säkerhet + arkitektur + affär)
- **Uppdateringsfrekvens**: kvartalsvis granskning; akuta ändringar via snabbspår (dubbelsignering + 24h offentliggörande)
- **Ändringslogg**: se `CLAUDE_CHANGELOG.md`
- **Hantering av överträdelser**: första överträdelsen = varning + obligatorisk utbildning; andra överträdelsen = avstängning från AI-verktyg; tredje = indragen behörighet

Den här skelettstrukturen är inte “facit” – den är en “mall att fylla i”. Vad du fyller i varje fält är viktigare än hur mycket du skriver – de tomma fälten avslöjar exakt vilka delar av verksamheten som “inte är genomtänkta”.

Ett typiskt exempel: en affärsbank definierade i sin CLAUDE.md specifika regler för lösenordshantering – AI-genererad kod som rör lösenord måste anropa bankens interna nyckelhanterings-API, hårdkodning är förbjudet. Den här typen av regler står för en stor andel av de avvisade ärendena i compliance-granskningar.

En viktig nyhet under H1 2026 är Skills/arbetsflödesdefinitioner – inte bara dokumentation, utan verktygskedjor som AI:n faktiskt kan anropa. Claude Codes Skills-system (som gick in på Anthropics officiella marknadsplats i februari 2026, 112 000 stars på GitHub) gör att arbetsmoment som “läsa Excel-filer”, “generera SQL” och “köra datamigrering” blir delbara arbetsflöden. Det här är den viktigaste utvecklingen inom specifikationsdriven utveckling under H1 2026: specifikationer är inte bara begränsningar – de är exekverbara arbetsflöden.

Fas tre: institutionalisering (pågående).

Att skriva regler är inte slutet – det är början. Du måste göra dem till en del av organisationens processer:

  • CI-gating: Automatiska kontroller som säkerställer att koden följer reglerna (t.ex. detektera hårdkodade lösenord eller okrypterade känsliga fält)
  • Delade teamkonfigurationer: Använd Skills-systemet så att hela teamet arbetar utifrån samma regelverk
  • Regelbunden uppdatering: När förutsättningarna ändras måste reglerna följa med (kvartalsvis översyn)
  • Mätning och återkoppling: Följ upp defektfrekvens i AI-genererad kod, regelefterlevnad vid granskning och omarbetningsgrad
  • Agentstyrning: Utvidga styrningen från människor till AI-agenter – det Atos gör med Agent 365 handlar om att göra detta till en “systemnivå” snarare än “individnivå”

EY och Atos har under första halvåret 2026 båda gjort fas tre till en “organisatorisk förmåga”. EY:s besparing på 2,5 miljoner timmar beror på att fas ett och tre gjordes rätt – fas två handlade bara om att översätta reglerna till dokument som AI kan läsa.

5. Starkt reglerade varianter: Tre ingenjörsmässiga sätt att bädda in regelefterlevnad

Inom starkt reglerade branscher som finans, telekom och sjukvård är regelstyrd implementering ett steg tuffare än i generella branscher – regelefterlevnad är inte ett externt tillägg till processen, utan inbyggt i koden. De tre metoderna nedan är beprövade sätt att integrera regelefterlevnad som verifierats under första halvåret 2026, och som CIO:er och digitaliseringsansvariga direkt kan använda i sin organisationsdesign.

5.1 Inbäddade compliance-representanter i strömteam: Låt compliance vara “närvarande” snarare än “godkännande”

Det traditionella tillvägagångssättet: affärsteamen skriver kod, compliance-teamet granskar i efterhand – när granskningen hittar problem har koden redan varit i produktion i två veckor, och omarbetningen kostar 2–4 veckor. Kärnproblemet är att compliance sitter i slutet av processen.

Det nya tillvägagångssättet: bädda in compliance-representanter i varje strömteam (stream-aligned team), med en dual-rapporteringsmodell där de rapporterar “solidt” till compliance-avdelningen men “prickat” till affärsteamet. Konkret utformning:

  • Bemanning: En compliance-representant per 6–8 strömteam, organisatoriskt placerad på compliance-avdelningen men fysiskt sittande med affärsteamet – inte som en tillfällig “utlåning”
  • Prickade KPI:er: 50 % av compliance-representantens vikt ligger på affärsteamets “compliance-defektfrekvens” och “godkännandegrad vid första granskning”, inte enbart på compliance-avdelningens “revisionstäckning”
  • Tidigt engagemang: Compliance-representanten deltar i dagliga standups (en gång i veckan räcker), granskar PR:er, och AI-genererad kod måste passera compliance-representanten innan merge – inte upptäckas i efterhand och åtgärdas
  • Verktygsstöd: Compliance-representanten använder Skills-anrop för compliance-checklistor, inte manuell punkt-för-punkt-genomgång

Typiskt scenario: En rikstäckande aktiebank genomförde under första halvåret 2026 en pilot med tre strömteam där compliance-representanter var inbäddade, och minskade andelen återlämnad AI-kod från 35 % till 8 % – kärnan är inte att compliance “granskar hårdare”, utan att compliance “ser tidigare”. Nyckeln här är att compliance-representanternas sidledda incitament måste vara linjerade med affärsmålen – om deras KPI:er fortfarande bara mäter uppgifter från complianceavdelningen är inbäddningen ett misslyckande.

5.2 Compliance som enabling team: förvandla begränsningar till affordances

Traditionellt tillvägagångssätt: Compliance-teamet är “grindvakter” och affärsteamen ser compliance som “besvärsskapare”. Det blir ett nollsummespel mellan parterna.

Nytt tillvägagångssätt: Compliance-teamet omstruktureras enligt Team Topologies enabling team-modell – de skriver inte kod direkt, granskar inte PR:er direkt, men tillhandahåller tre saker som gör att affärsteamen kan “självbetjäna compliance”:

  1. Compliance-kontroller i CI-pipelinen: Högfrekventa compliance-punkter som hårdkodade lösenord, känsliga fält i klartext, gränsöverskridande dataöverföring och algoritmiska beslutsnoder byggs in som tvingande grindar i GitHub Actions / GitLab CI. En PR från affärsteamet utlöser automatisk granskning – bristande efterlevnad failar direkt, utan att en compliance-handläggare behöver gå igenom manuellt.
  2. Regulatoriska krav som affordance (miljöbaserade begränsningar): När en utvecklare bygger funktioner som hanterar kunddata, poppar IDE-pluginen upp “detta fält rekommenderas att anropa KMS”; vid loggning detekteras automatiskt om känslig information ingår och larm utlöses. Compliance-kraven blir “naturliga handlingar i utvecklingsflödet”, inte “att få veta att man brutit mot regler vid lansering”.
  3. Delat Skills-bibliotek + compliance-utbildning: Compliance-teamet underhåller en samling “Compliance Skills” som direkt kan anropas vid nyanställning / byte av team – compliance-kunskap omvandlas från “dokument” till “exekverbara verktyg”.

Typiskt scenario: En regional bank lanserade CI-compliance-grindar + IDE-compliance-påminnelser under H1 2026 och minskade den genomsnittliga tiden för AI-kodgranskning ur compliance-perspektiv från 45 minuter per tillfälle till 8 minuter per tillfälle. Kärnan är inte att compliance-granskningen “blivit snabbare” – det är att AI-genererad kod “inte gör fel” från början.

5.3 Dubbel hastighet för compliance: skiktad anpassning till affärstakten

Sista detaljen: regelefterlevnad ska inte vara “en modell som passar alla”. Dela upp reglerna i två nivåer baserat på riskgrad:

  • Högriskregler (som rör kundmedel / algoritmiska beslut / data över landsgränser / säkerhetskritisk infrastruktur) följer strikt styrning: kräver manuell granskning + dubbelbekräftelse från AI + registrering i Change Advisory Board (Change Advisory Board (CAB))
  • Lågriskregler (CRUD-mallar / verktygskod / dokumentgenerering) följer självbetjäningsstyrning: räcker med automatisk kontroll i CI, ingen manuell granskning krävs

Atos Agent 365:s kontrollplan bygger i grunden på just denna uppdelning – olika nivåer av agenter binds till olika styrningskrav. Genom att skikta reglerna efter risk kan företagsteamen känna att “efterlevnad inte är ett hinder överallt”.

Sammantaget om dessa tre saker: att bädda in regelefterlevnad är inte att lägga till en process – det är att designa om teamets struktur och incitament. Om er efterlevnadsavdelning fortfarande arbetar i “granska i efterhand”-läge, kommer det regeldrivna införandet att fastna i det svåraste steget: institutionalisering. Efterlevnadsavdelningen måste först genomgå sin egen omställning, för att affärsteamen ska kunna driva det regeldrivna arbetet smidigt.

VI. Frågor du kanske ställer

“Vi har redan kodstandarder – vad är skillnaden?”

Kodstandarder handlar om hur man skriver kod; regeldrivet arbete handlar om hur man samarbetar med AI. Kodstandarder inkluderar inte: affärsregler, krav på regelefterlevnad eller policyer för AI-användning. Regeldrivet arbete handlar om att göra “hela flödet av människa–AI-samarbete” explicit – det är inte en stilguide för kod.

“Skriver regler och riktlinjer – sänker det utvecklingstakten?”

Kortsiktigt ja, långsiktigt nej. CodeRabbit har tydliga siffror på detta: kod utan styrning från AI löper cirka 1,7 gånger högre risk för defekter och 2,74 gånger högre risk för säkerhetsbrister. Inom finanssektorn innebär en enda regelefterlevnadsgranskning som måste göras om 2–4 veckors försening – att slippa ett enda sådant omtag räcker för att finansiera en hel månads arbete med att ta fram riktlinjer. Att EY sparade 250 miljoner dollar handlar om att göra detta till en organisatorisk förmåga – det är det verkliga beviset.

“Vad gör vi om ingen i teamet kan skriva riktlinjer?”

Ni behöver inte börja från noll. GitHub Spec Kit, Claude Code Superpowers och AWS Kiro har alla färdiga mallar. Allt ni behöver göra är att fylla i era egna organisationsspecifika regler – och det mesta handlar om regelefterlevnad och säkerhet. Dessa regler finns redan nedskrivna av era compliance- och säkerhetsavdelningar – problemet är bara att de inte ligger på en plats där AI:n kan komma åt dem.

“Det finns så många AI-verktyg – vilket ska vi välja?”

Oviktigt. Välj det ni redan använder. Regelverket är verktygsoberoende – CLAUDE.md fungerar i Claude Code, Cursor och Codex; AGENTS.md kör i OpenAI-ekosystemet; constitution.md är modellagnostiskt. Det viktiga är att skriva regelverket, inte att byta verktyg. EY rullar ut inom Microsoft-ekosystemet, Atos rullar ut inom Microsoft-ekosystemet – valet av verktyg är bara yta, enhetligheten i styrarkitekturen är det som räknas i grunden.

“I augusti 2026 träder EU:s AI-förordning (AI Act) i full kraft – påverkar det oss?”

Ja. EU:s AI-förordning (AI Act) träder i full kraft den 2 augusti 2026 och ställer tvingande krav på högrisksystem för AI – inklusive kreditgivning, försäkringsprissättning, anställningsscreening och kritisk infrastruktur – inom områdena riskhantering (art. 9), datastyrning (art. 10), dokumentation och transparens (art. 11–13), mänsklig tillsyn (art. 14) samt noggrannhet och robusthet (art. 15). Bötesbeloppet uppgår till högst 35 miljoner euro eller 7 % av den globala omsättningen. För kinesiska företag som expanderar utomlands är EU-marknaden ett måste; för inhemska aktörer är AI Act den referensram som citeras mest världen över – du kanske inte omfattas direkt, men du kan knappast undvika dess indirekta effekter på dina leverantörer, partners och gränsöverskridande verksamhet (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

“Svensk motsvarighet: EU reglerar AI – vad reglerar vi?”

Kinas styrning av generativ AI bygger på tre pelare: algoritmregistrering (算suàn法fǎ备bèi案àn), korpusgranskning och säkerhetsbedömning. Den centrala förordningen är de interimistiska åtgärderna för hantering av generativa AI-tjänster, som trädde i kraft i augusti 2023. Den största skillnaden ligger inte i detaljrikedomen utan i den bakomliggande regleringsfilosofin:

DimensionEU:s AI-förordningKinas “Förvaltningsåtgärder för generativa AI-tjänster”
Rättslig ställningHorisontell reglering (tillämplig på alla AI-system)Vertikal reglering (fokuserad på generativa AI-tjänster)
Riskklassificering4 nivåer (oacceptabel / hög / begränsad / minimal)2 nivåer (samhällsopinionsrelaterad / allmän kommersiell)
TillsynstidpunktFörhandsreglering (registrering redan vid utveckling)Efterhandsreglering (registrering efter lansering + algoritmregistrering)
TransparensHög (krav på offentliggörande av sammanfattning av träningsdata, modellkort)Medel (krav på korpusregelefterlevnad men ingen tvingande offentliggöring av källor)
Maxstraff7 % av global omsättning eller 35 miljoner EURTjänstestopp / böter (vanligtvis multiplar av olaglig vinst)
TillämpningsområdeAlla företag över tröskeln för global omsättningAlla aktörer som tillhandahåller tjänster inom Kinas territorium

Sju: Lärdomar för beslutsfattare

I praktiken är AI-system inom kinesiska finansinstitut vanligtvis samtidigt föremål för tre regelverk — “Generativa AI-förvaltningsåtgärder” (grundlager), “Förvaltningsåtgärder för internetlån inom kommersiella banker” (verksamhetslager), samt skyddsklassning (等保, dengbao — kinesisk motsvarighet till ISO 27001) och algoritmregistrering (kompatibilitetslager). Detta innebär att den som vill arbeta regelstyrt i Kina inte kan kopiera EU:s AI-förordning rakt av — man måste skriva in de tre inhemska spåren “korpuskompatibilitet + algoritmregistrering + tillsynsrapportering” i CLAUDE.md.

För företag som går utomlands: EU AI-förordningens fyra hörnstenar — “riskhantering + datastyrning + dokumentationstransparens + mänsklig tillsyn” — är också den riktning som den kinesiska tillsynen gradvis anpassar sig till. Redan 2025 har flera återkopplingar från Cyberrymdens administratörs registreringsförfaranden för generativ AI tydligt lånat från EU:s detaljeringsgrad. Den som skriver EU AI Act-kompatibla regler idag har med stor sannolikhet också täckning för den skärpta inhemska tillsynen under de kommande tre åren (CAC:s registreringsmeddelanden 2025–2026; EU AI Act-efterlevnad juni 2026).

Lärdom ett: Att skriva en CLAUDE.md/AGENTS.md-projektstandard är den enskilt högsta ROI-åtgärden inom ingenjörskonst i AI-eran.

Dess investering är 3–8 veckors struktureringsarbete + 1–2 veckors dokumentation. Avkastningen: defektrisken begränsas till cirka 1,7 gånger, säkerhetsbrister minskar med 2,74 gånger, och omarbetningsgraden sjunker med över 40 %. Inom finanssektorn räcker det med att slippa en enda omarbetad regelefterlevnadsgranskning (2–4 veckor) för att täcka kostnaden. EY rullade ut Copilot till 150 000 anställda och sparade 250 miljoner dollar – men först efter att de hade ordning på sina riktlinjer.

Insikt två: Riktlinjer är en organisatorisk förmåga, inte ett verktygsval.

Oavsett om du väljer GitHub Spec Kit eller Claude Code spelar mindre roll. Det viktiga är om du har definierat “hur vår organisation samarbetar med AI”. Utan det kommer även de bästa verktygen bara att låta teamet bygga upp mer teknisk skuld i snabbare takt.

Insikt tre: Skriv in riktlinjerna i organisationens processer, förlita dig inte på enskilda individer.

Om riktlinjerna bara finns i huvudet på en senior utvecklare försvinner de när personen slutar. De måste förankras i repo-dokumentation, CI-gates, delade teamkonfigurationer och agentstyrningsplattformar. Gör riktlinjerna till en organisatorisk tillgång, inte en personlig färdighet. Atos 19 000 agenter fungerar i 54 länder eftersom styrningen inte handlar om att “någon förstår” – den är “systemtvång”.

Insikt fyra: Gates är viktigare än hastighet.

GitHub Spec Kit:s femfasiga grindar, Superpowers princip om “ingen kod innan tester misslyckats” och Kiros krav på spec innan uppstart – allt handlar om att sätta en broms mellan AI och slutresultatet. Ju starkare AI-kapacitet, desto viktigare blir styrningen. De 78 procenten incidenter i New Relics 2026-rapport är priset för att 62 procent av teamen “skickar utan granskning”. CIO:er inom finans branschen förstår detta bäst: era Change Advisory Boards (Change Advisory Board (CAB)), algoritmregistrering och säkerhetsklassningar (ISO 27001 + MSB 系统性安全方法, motsvarande SOC 2/HIPAA) är alla grindar före produktion. AI-genererad kod behöver samma typ av grindar – och de måste ligga ännu tidigare i processen.

Självkontroll (var ärlig i svaret): Brukar er granskning av AI-genererad kod ofta skickas tillbaka för omarbetning? Vad var det senaste problemet som orsakades av AI-kod? Om du frågar er tekniska ledare “hur samarbetar vi med AI” – kan hen då ta fram ett dokument? Om du inte kan svara på någon av de tre frågorna har ni ännu inte implementerat styrning genom specifikationer – skriv specifikationerna först, köp verktygen sedan.

Tre coachningsfrågor för beslutsfattare

Avslutningsvis tre frågor – inte en checklista, utan frågor du kan använda direkt i diskussioner med ditt team:

  1. “Om alla AI-verktyg försvann i morgon – hur mycket skulle er kodkvalitet sjunka?” — Den här frågan blottlägger det verkliga värdet av specifikationsdriven utveckling: om svaret är “markant”, har era specifikationer ännu inte satt sig; om svaret är “nästan oförändrat”, kör ni redan på rätt spår.
  2. “I ert specifikationsdrivna projekt – är complianceavdelningen en ‘grindvakt’ eller en ‘möjliggörare’?” — Om svaret är “grindvakt” kommer er leveranstakt att fastna i granskningsflaskhalsar; om svaret är “möjliggörare” har ni redan hittat rätt väg enligt avsnitt 5.2.
  3. “Om 12–18 månader – hur förändras er teamstorlek?” — Microsofts WTI 2026-rapport visar att 82 % av ledarna kommer att “skala upp” arbetsstyrkan med AI-agenter. Om ert svar är “oförändrad” betyder det antingen att er verksamhet inte växer, eller att er organisationsdesign inte hunnit ikapp specifikationsdrivningens fördelar.

Det finns inga givna svar på dessa tre frågor. Men riktningen på svaren väger tyngre än svaren i sig.

Nästa steg

Detta är den sjätte delen i serien om mjukvaruutvecklingens omvandling i AI-eran. Från Conway (organisationen bestämmer arkitekturen) till Team Topologies (hur man designar organisationen), vidare till flaskhalsförskjutningen (flaskhalsen ligger i verifieringen, inte i kodningen) – och idag: specifikationsdriven utveckling (att styra AI-beteende med dokumentation).

Nästa del (sjunde) tittar vi på den underliggande infrastrukturen som bär allt detta — MCP-protokollet (Model Context Protocol): varför Anthropics öppna protokoll kallas “AI:ns USB-C”, varför OpenAI, Google och Microsoft alla har anslutit sig, och hur det möjliggör interoperabilitet mellan flera verktyg och agenter.

Vill du omsätta det här i din organisation?

När regelstyrning införs i ett företag handlar det i praktiken oftast om några konkreta frågor: hur kärnreglerna ska formaliseras i CLAUDE.md / AGENTS.md, hur befintlig kod ska anpassas till reglerna, hur regelefterlevnad integreras, och vilka mätetal som ska användas för att utvärdera piloten.

Vi erbjuder tre former av samarbete:

  • Internutbildning: Utifrån era verkliga projekt — strukturering av regelverk, design av CI-grindar, vägar för regelefterlevnad och uppbyggnad av styrningsmekanismer.
  • Specialiserad rådgivning: Fokuserad på ett tydligt beslut, till exempel “ska vi skriva CLAUDE.md / AGENTS.md först?” eller prioritering av regelefterlevnad för befintlig kod.
  • Ledningspresentationer och branschtal: Kring AI-programmeringsverktyg, regelstyrning, organisationsstyrning och Frontier Firms.

Artikeln kan ge en generell ram. Den konkreta implementeringen måste fortfarande utformas utifrån företagets regelefterlevnad, tillsynsgränser, teknisk mognad och befintliga leveransprocesser. Samarbete kan kontaktas via coach@iaiuse.com.

Vidare läsning: ”Skyltskyltmetoden v1.0” (Lär dig AI långsamt 187), som systematiskt presenterar en ram med 7 steg för AI-omställning i företag.

Om denna serie

”Förändring av mjukvaruutveckling i AI-eran” är en forskningsserie för CIO:er, CDO:er, CTO:er och digitaliseringsansvariga inom telekom, finans, tillverkning och e-handel. Serien omfattar 18 delar och fokuserar på hur AI-programmeringsverktyg, regelstyrning och organisationsstyrning påverkar mjukvaruleveransprocesser, organisationsstruktur och teknisk mognad.

Serien följer löpande akademiska uppsatser, leverantörsdokumentation och branschrapporter. Forskningsdatabasen omfattar över 200 källor, och viktiga slutsatser förses med evidensnivåer för att i möjligaste mån skilja mellan verifierade fakta, leverantörspåståenden, branschobservationer och författarens resonemang.

Jag har nära 8 års erfarenhet av konsultverksamhet och affärsanalys i stora företag, med tidigare anställning på IBM och projekt inom telekom, finans, försäkring och tillverkning. Därefter har jag fortsatt arbeta i frontlinjen med operatörsprodukter, internetprodukter och AI-applikationsutveckling, med fokus på kravanalys, produktdesign och tvärfunktionell implementering.

Den här serien om styrningsdriven, organisationsmässig och ingenjörsmässig bedömning bygger på dessa praktiker, och korsvalideras med offentlig forskning och branschfall. Innehåll som rör specifika projekt har avidentifierats; vissa branschscenarier är typiska problemanalyser, och underlaget finns i referenserna i slutet.

Bakom den här kanalen står faktiskt ett litet team – jag och 1–2 kollegor som jag arbetat långsiktigt med, där vi delar upp ansvaret för forskning kring AI-programmeringsverktyg, organisationsstyrningsfall och coachande dialoger. De flesta projekt där vi “följt företag genom” i texten har vi levererat tillsammans. Vi nämner fortfarande inte kunders namn eller juridiska gränser – anonymiteten ger utrymme för framtida samarbetspartners.

Referenser (samtliga verifierade, med evidensnivå markerad per punkt)

  • CodeRabbit (2025.12). State of AI vs Human Code Generation Report. AI-genererad kod innehåller 1,7 gånger fler problem än mänskligt skriven kod (10,83 vs 6,45 problem per pull request), logik/korrekthet 1,75×, kodkvalitet 1,64×, säkerhet 1,57×, lösenordshantering 1,88×, XSS 2,74×. Evidensnivå: 1. Källa: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263

  • The Register (2025.12.17). Rapportering av CodeRabbits fullständiga rapport: analys av 470 open source-pull requests visar att AI-assisterade PR:er innehåller 10,83 problem jämfört med 6,45 för rent mänskligt skrivna. Evidensnivå: 2. Källa: samma URL som ovan

  • CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap” – 2026 blir året då fokus skiftar från “kodgenereringshastighet” till “kodkvalitet och styrning”. Evidensnivå: två. Källa: https://tfir.io/ai-code-quality-2026-guardrails

  • New Relic (2026). The 2026 State of AI Coding Report. 78 % av teamen rapporterar fler incidenter efter att AI-genererad kod satts i produktion; 62 % av tech-ledarna medger att teamen “självsäkert skickar iväg AI-kod utan granskning”; 96 % anser att observerbarhet är ett måste. Evidensnivå: ett (leverantörsrapport). Källa: https://newrelic.com/resources/report/2026-state-of-ai-coding

Microsoft 2026 Work Trend Index Annual Report (2026.5.5)

20 000 AI-arbetare tillfrågade, 10 länder; 82 % av ledarna planerar att utöka arbetsstyrkan med AI-agenter inom 12–18 månader; 81 % förväntar sig måttlig eller omfattande integrering av AI-agenter; 24 % har redan implementerat på företagsnivå; 49 % uppger att Copilot-dialoger stödjer kognitivt arbete; 58 % av AI-användarna gör saker de “inte kunde göra för ett år sedan” – bland Frontier Professionals stiger den siffran till 80 %. Evidensnivå: 1. Källa: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf

  • Microsoft FY26: Från AI-experiment till frontlinjetransformation (2026.07.28). EY rullade ut Microsoft 365 Copilot till 150 000 anställda, vilket sparade 2,5 miljoner timmar och cirka 250 miljoner USD; utbyggnaden utökades till 400 000 globala medarbetare, med 95 % snabbare processer, 37 % lägre finansiella driftkostnader och upp till 90 % minskning av manuella arbetsflöden. Atos distribuerade Copilot till 56 000 anställda i 56 länder plus 19 000 AI-agenter, med en enhetlig kontrollplan för identitet, säkerhet, regelefterlevnad och styrning. Bevisnivå: primär (officiell Microsoft-retrospektiv). Källa: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Atos Group och Microsofts strategiska samarbete (2026-06-09). Atos inför Microsoft 365 E7 (Frontier Suite) för 56 000 anställda i 56 länder, tillsammans med 19 000 AI-agenter; enhetlig kontrollplan för Entra/Defender/Intune/Purview/Agent 365. Bevisnivå: 1 (gemensamt pressmeddelande från båda parter). Källa: 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 (öppen källkod 2025.9, vidareutveckling 2026 H1). 5-stegs grindkontroll /speckit.constitution → /specify → /plan → /tasks → /implement, plus /clarify /analyze; modellagnostisk (Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code kan alla anslutas). Evidensnivå: nivå 1. Källa: https://github.com/github/spec-kit

  • AWS Kiro (lanserat 2025.7, vidareutveckling 2026 H1). Trestegs arbetsflöde: krav → design → uppgifter; spec utlöser fördefinierade agentåtgärder; utan spec går det inte att starta. Evidensnivå: nivå 1. Källa: https://kiro.dev/

  • OpenAI Codex + AGENTS.md + Skills (2025–2026). Codex hade över 5 miljoner aktiva användare i veckan i juni 2026, varav 20 % icke-utvecklare; AGENTS.md + Skills utgör ett kombinerbart instruktionspaket. Evidensnivå: primär (officiellt tillkännagivande från OpenAI). Källa: https://developers.openai.com/codex/skills

  • Claude Code (Anthropic, H1 2026). CLAUDE.md + .claude/rules/ + Skills-system; gick in på Anthropics officiella marknadsplats i februari 2026; Skills-repot har 112 000 stjärnor på GitHub; G-runda i februari 2026 visade på 2,5 miljarder USD i årlig återkommande intäkt. Evidensnivå: primär. Källa: https://code.claude.com/docs/en/claude-directory

  • JetBrains AI Pulse Survey (2026.1). En global undersökning bland 10 000+ professionella utvecklare, lokaliserad till 8 språk; Claude Code CSAT 91% / NPS 54 (högst i branschen); Claude Code arbetsplatsanvändning 18% (från 3% till 18% på 9 månader, en sexfaldig ökning), i Nordamerika 24%; Copilot 29% arbetsplatsanvändning men tillväxten har stannat av; Cursor 18%. Evidensnivå: 1. Källa: https://www.jetbrains.com/lp/tools/ai-tools/

  • Pragmatic Engineer Newsletter (2026.2). Undersökning bland 15 000 utvecklare; 46% valde Claude Code som “mest omtyckt”, Cursor 19%, Copilot 9%. Evidensnivå: 1. Källa: https://newsletter.pragmaticengineer.com/

  • Alibaba Qoder (2025.8 → 2026.7). Lanserades av Alibaba i augusti 2025; den 15 maj 2026 uppgraderades Qoder 1.0 till en Autonomous Agent Development Workbench; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; den 28 maj 2026 kom Cloud Agents (hanterad agentkörningsmiljö); den 21 juli 2026 lanserades Qoder Security; i maj 2026 passerade man 5 miljoner globala användare; CLI-integrering med DingTalk; den 20 maj 2026 bytte Tongyi Lingma namn till Qoder CN. Bevisnivå: 1. Källa: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525

  • vibecoding.app / thebcms.com / tfir.io (första halvåret 2026). Femfasiga kommandon för Spec Kit, jämförande utvärderingar av SDD-verktyg samt annoteringsmetoden EARS. Bevisnivå: två:a graden (oberoende utvärderingar). Källa: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development

  • EU AI Act / Code of Practice (fullt i kraft 2026-08-02). Efterlevnadskrav för AI-system med hög risk senast 2026-08-02; befintliga GPAI-modeller förlängs till 2027-08-02; böter upp till 35 miljoner euro eller 7 % av global omsättning; Art. 9–15 om riskhantering, datastyrning, dokumentationstransparens, mänsklig tillsyn, noggrannhet och robusthet. Evidensnivå: 1 (lagstiftning + sekundär efterlevnadsanalys). Källa: 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). 44 % av problemen har sin grund i bristande kontext. Evidensnivå: 2 (leverantörsrapport). Källa: https://www.qodo.ai/reports/state-of-ai-code-quality/

Lär dig AI - en resa med IAIUSE

Som en erfaren AI-konsult har jag sett många företag gå från att vara skeptiska till AI till att bli fullständigt övertygade om dess potential. I den här artikeln kommer jag att dela med mig av mina erfarenheter och tips för hur du kan börja din resa med AI.

Vad är AI?

AI står för Artificiell Intelligens, och det är en teknik som låter maskiner lära sig och utföra uppgifter på egen hand. Det finns många olika typer av AI, från enkla algoritmer till mer komplexa neurala nätverk.

Varför börja med AI?

Det finns många anledningar till varför du bör börja med AI. För det första kan AI hjälpa dig att automatisera uppgifter och öka effektiviteten i ditt företag. För det andra kan AI hjälpa dig att förbättra kundupplevelsen och öka försäljningen.

Hur börjar man med AI?

Det första steget är att identifiera vilka problem du vill lösa med AI. Sedan kan du börja att undersöka olika lösningar och tekniker. Det är viktigt att välja en teknik som passar dina behov och resurser.

Exempel från olika branscher

  • I telekombranschen kan AI hjälpa till att förbättra nätverksprestanda och minska fel.
  • Exempel: AT&T har använt AI för att förbättra sin kundservice och minska fel.
  • I bankbranschen kan AI hjälpa till att förbättra riskhantering och minska bedrägerier.
  • Exempel: Deutsche Bank har använt AI för att förbättra sin riskhantering och minska bedrägerier.
  • I tillverkningsbranschen kan AI hjälpa till att förbättra produktionsprocessen och minska fel.
  • Exempel: Toyota har använt AI för att förbättra sin produktionsprocess och minska fel.
  • I e-handelsbranschen kan AI hjälpa till att förbättra kundupplevelsen och öka försäljningen.
  • Exempel: Amazon har använt AI för att förbättra sin kundupplevelsen och öka försäljningen.

Hur kan du börja med AI?

Det första steget är att identifiera vilka problem du vill lösa med AI. Sedan kan du börja att undersöka olika lösningar och tekniker. Det är viktigt att välja en teknik som passar dina behov och resurser.

Resurser

  • IAIUSE - en plattform för AI-lösningar
  • Trae - en AI-plattform från ByteDance
  • Vertex AI - en AI-plattform från Google
  • AWS Bedrock - en AI-plattform från Amazon

Sammanfattning

AI är en teknik som kan hjälpa dig att lösa många olika problem. Det är viktigt att identifiera vilka problem du vill lösa och sedan undersöka olika lösningar och tekniker. Med rätt teknik och resurser kan du börja din resa med AI och uppnå stora framsteg.

]]> AI-kodfel 1,7×, säkerhetsbrister 2,74× — AI ser inte dina regler. Spec Kit, Kiro, Codex, Claude Code, Qoder går 2026 H1 mot CLAUDE.md. Специфікація як рушійна сила — Spec-Driven Development в епоху ШІ та трансформація програмної інженерії https://iaiuse.com/uk/posts/spetsyfikatsiya-yak-ruhiyna-syla-spec-driven-development-napysannya-spetsyfikatsii-nayvyshchyi-roi-v-epokhu-shi-transformatsiya-programnoi-inzhenerii 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z

Джерела даних у статті: CodeRabbit 2025.12 / New Relic 2026 report, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms announcement, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. Кейси є узагальненням типових сценаріїв і не прив’язані до конкретних компаній.

Ваша найбільша помилка — не те, що ви не купили інструменти, а те, що ви не написали CLAUDE.md

Один ІТ-директор ПриватБанку поскаржився мені: інструменти зі штучним інтелектом купили, моделі розгорнули, людей навчили — а за перше півріччя 2026 року цикл поставки майже не зрушився з місця. Керівник команди, що відповідає за ядро системи, висловився ще прямолінійніше: «Код, який пише ШІ, можна використати, але щоразу доводиться переписувати його з нуля — він не розуміє наших банківських правил, не розуміє регуляторних вимог, не розуміє, як інтегруватися з тією 30-річною легасі-системою».

Проблема не в тому, що AI недостатньо потужний, — а в тому, що ви не записали правила. У грудні 2025 року CodeRabbit опублікував аналіз 470 відкритих pull request-ів, і ці цифри потім широко цитували: у PR, створених за участі AI, у середньому 10,83 проблеми, у суто ручних — 6,45. У 1,7 раза більше — тобто на 70% більше багів, ніж у ручній роботі. До 2026 року картина не змінилася: New Relic у своєму звіті 2026 State of AI Coding Report виявив, що 78% команд повідомляють про більше інцидентів після впровадження AI-коду, а 62% технічних лідерів визнають, що їхні команди «впевнено відправляють AI-код у прод без порядкового рев’ю» (офіційний звіт New Relic, 2026, оцінка 0,866, первинне джерело). Обидва набори даних говорять про одне й те саме: AI не бракує здібностей — йому бракує контексту.

Звернімося до реального болю того самого CIO. AI у трьох конкретних збоях фінансових ядр:

Перше: AI не бачить 30-річної логіки звірки. Правила ризик-менеджменту банку зашиті в збережених процедурах ядра системи — написаних 30 років тому, ніхто не пам’ятає їх повністю. AI генерує код, який виглядає коректно, але в продакшені запускає ту забуту перевірку звірки, через яку падає вся партія транзакцій.

Друге: AI не бачить комплаєнс-обмежень. Паролі повинні йти через систему керування ключами, чутливі поля — шифруватися, логи не повинні друкувати клієнтську інформацію. Це жорсткі регуляторні обмеження, зафіксовані у внутрішніх регламентах. AI про них не знає — і код працює, але не проходить комплаєнс-перевірку.

Третє: AI не бачить вашого технічного боргу. Та 30-річна хост-система використовує власний протокол інтерфейсів, документація давно загублена. AI пише код за загальними RESTful-канонами, а на продакшені виявляється, що інтерфейси не збігаються — і два тижні повернення на доопрацювання.

Повертаючись до інших цифр New Relic: 62% команд «впевнено публікують без рев’ю», а 78% повідомляють про більше інцидентів після випуску. Разом вони кажуть: проблема не в рівні дефектів AI-коду, а в тому, що ніхто не знає, які дефекти там є.

Типовий сценарій: один із банків впровадив AI-допомогу для розробки модуля контролю ризиків у ключовій системі. Протягом трьох місяців частка відхилень під час комплаєнс-перевірки помітно зросла. Основні проблеми — внутрішні правила щодо керування паролями, шифрування чутливих полів, логування для відповідності вимогам тощо. Ці правила були описані у внутрішній документації, але AI їх не бачив. Згодом команда записала ключові правила у файл CLAUDE.md — і частка відхилень суттєво знизилася.

Станом на серпень 2026 року будь-яку наративу про «прискорення AI-трансформації» варто розглядати крізь призму такого зіставлення:

| Табір | Прогрес (H1 2026) | Контрприклад (H1 2026) |
|—|—|—|—|
| EY | Microsoft 365 Copilot розгорнуто для 150 000 співробітників, економія 2,5 млн годин / 250 млн доларів; масштабування на 400 000 працівників по всьому світу | Водночас визнають, що прискорення на 95% і зниження операційних витрат у фінансах на 37% можливі лише за умови «спочатку стандартизація» |
| Atos | Розгортання в 54 країнах / для 56 000 співробітників; одночасно працюють 19 000 AI-агентів під єдиною площиною контролю для ідентичності, безпеки, комплаєнсу та керування | Жорстко дотримуються принципу «спочатку вивести на продакшн governance-можливості Agent 365, потім масштабуватися» |
| Сама Microsoft | Work Trend Index 2026: 82% керівників планують розширювати робочу силу за допомогою AI-агентів протягом 12–18 місяців | Водночас визнають, що «темпи організаційних змін відстають від індивідуального використання» — це ключове протиріччя в концепції Frontier Firm |

Джерело: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5; New Relic 2026 State of AI Coding Report.

Ці два зіставлення показують одне: без стандартів масштабування означає помножити ризик на N. «Швидкість» EY/Atos/Microsoft — це не швидкість моделі, а те, що «організація спершу відповіла на питання, як використовувати AI». Саме це пояснює, чому Spec-Driven Development (SDD, розробка, керована специфікаціями) у першій половині 2026 року справді став мейнстримом — не тому, що інженери полюбляють документацію, а тому, що без написання специфікацій уже неможливо вижити в середовищі з 19 000 агентів.

Ця стаття пояснює три речі: 1) чому дефекти в AI-коді є щонайменше в 1,7 раза серйознішими, ніж у коді, написаному людиною; 2) як GitHub, AWS, OpenAI, Anthropic та Alibaba — п’ять платформ — у першій половині 2026 року прийшли до однієї парадигми: обмежувати поведінку AI за допомогою документації; 3) чому розробка, керована специфікаціями, — це організаційна спроможність, а не вибір інструменту, і які три етапи впровадження відбулися в першій половині 2026 року.

AI-код проти людського коду: розподіл дефектів (проаналізовано 470 PR у відкритому коді) Звіт CodeRabbit 2025.12 | усі числа — кратності AI/людина (базова лінія 1.0)

Довжина стовпчика = дефекти AI як кратність до людських; базова лінія 1.0× = рівень людини

Базова лінія 1.0×

Усього проблем

1.7×
AI 10.83 проти людина 6.45 / PR

Помилки логіки / коректності

1.75×

Якість коду / підтримуваність

1.64×

Знахідки безпеки (сумарно)

1.57×

Неправильна обробка паролів

1.88×

XSS-вразливості

2.74×
↑ Найвищий

AI-код без специфікаційних обмежень перевищує людський за кожним виміром
Фінанси/телекому = узгодження комплаєнсу, управління паролями, шифрування чутливих полів — AI пропускає все

I. Рівень дефектів AI — це не проблема моделі, а проблема контексту

У звіті CodeRabbit є одна фраза, яку цитують постійно: «AI бракує локальної бізнес-логіки: модель робить статистичні висновки про патерни коду, а не розуміє семантику. Без жорстких обмежень вона пропускає системні правила, які старші інженери тримають у голові».

Це пояснює, чому власна AI-платформа CodeRabbit (компанія, що спеціалізується саме на AI-рев’ю коду) побачила ці дані раніше за інших — вони щодня переглядають тисячі pull request’ів і щодня бачать, як виглядає код, написаний штучним інтелектом. «Найважливіше» відкриття — не загальні цифри, а розподіл:

  • Логіка/коректність +75%: помилки бізнес-логіки, помилки залежностей, помилки потоку керування, помилки конфігурації — такі проблеми не завжди спливають під час тестування, але призводять до інцидентів у продакшені.
  • Якість коду +64%: неузгодженість найменувань, нечітка структура, порушення патернів проєкту — це «категорія з найбільшою різницею». Досвідчений інженер бачить з першого погляду: «це не наш стиль написання».
  • Безпека +57% (XSS-клас найвищий — 2.74×): неналежна обробка паролів (1.88×), небезпечні посилання на об’єкти (1.91×), витік чутливої інформації, небезпечна десеріалізація (1.82×) — у фінансовій галузі це питання не «чи працює», а «чи можна це взагалі випускати».

Проблема не в тому, що AI недостатньо потужний. Проблема в тому, що він не бачить.

II. П’ять платформ у першій половині 2026 року: різні шляхи, спільний вектор — «керування через специфікації»

У липні 2025 року GitHub випустив Spec Kit. На початку 2026 року AWS Kiro, OpenAI Codex та Anthropic Claude Code — усі доповнили свої продукти відповідними функціями. У травні 2026 року Alibaba Qoder закріпив «Spec-Driven Workflow» у позиціонуванні продукту. До першої половини 2026 року всі п’ять платформ дійшли до спільної парадигми — використання документації для обмеження поведінки AI. Це не винахід однієї компанії, а колективна відповідь індустрії на «кризу якості AI-коду».

Шляхи, керовані специфікаціями, на п'яти платформах (2025–2026 H1) GitHub Spec Kit Open source 2025.9 constitution.md П'ятиетапний гейт: constitution → specify → plan → tasks → implement Не залежить від моделі, підтримує 8+ агентів Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md Триетапний робочий процес: Вимоги → Дизайн → Завдання Підхід через специфікації вбудовано в робочий процес IDE Автоматичні агенти, що запускаються через хуки Хуки комплаєнсу/аудиту встановлено заздалегідь Не запускається без специфікації OpenAI Codex 2025-2026 AGENTS.md + система Skills Компоновані набори інструкцій Спільна конфігурація на рівні команди 5M+ щотижневих активних (2026.6) Не розробники 20% Від коду до універсальних агентів Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + Skills (офіційний маркет 2026.2) + MCP екосистема CSAT 91% / NPS 54 $2.5B ARR（2026.2） GitHub 112 тис. зірок Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Quest Mode автономне виконання + Expert Mode команда + RepoWiki контекст 5M+ користувачів у світі (2026.5) 2026.7.21 Qoder Security Microsoft Teams CLI інтегровано Спільна парадигма: явно записати "як ми співпрацюємо з AI" у документ і покласти в репозиторій Щоб усі люди й усі AI-агенти працювали за одним стандартом — це суть стандарт-орієнтованого підходу

Розгляньмо найсвіжіші дії кожної платформи в першій половині 2026 року:

GitHub Spec Kit: еталонна реалізація з п’ятиетапним гейтом. Відкритий у вересні 2025 року, до першої половини 2026-го він став галузевим еталоном. 5 основних команд + 2 додаткові: /speckit.constitution (непорушні принципи), /speckit.specify (що робимо і чому), /speckit.plan (як змінюємо), /speckit.tasks (декомпозиція на задачі), /speckit.implement (виконання), плюс /clarify і /analyze. Ключова особливість — модельна незалежність: одні й ті ж файли spec/plan/tasks не прив’язані до конкретного виконавця, їх підхоплюють Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf, Qwen Code. Це перетворює інструмент на «організаційний SDD-протокол», а не фірмовий продукт GitHub (оцінка vibecoding.app, червень 2026, 0.816 бала, вторинне джерело).

AWS Kiro: вбудовує специфікації прямо в IDE. Випущений у липні 2025 року, до першої половини 2026-го еволюціонував у повноцінну Agent IDE. Робочий процес складається з трьох етапів: вимоги → дизайн → завдання. Головна відмінність від Spec Kit — у «гачках»: spec-файли Kiro можуть запускати заздалегідь визначені дії агента, вбудовуючи кроки, що потребують зовнішніх систем (комплаєнс, аудит, деплой), прямо у робочий процес. Якщо хочете змусити команду писати специфікації — обирайте Kiro, бо без spec-файлу Kiro просто не запуститься (AWS Kiro official 2025.7; Kiro.dev docs 2026).

OpenAI Codex: AGENTS.md + компоновані Skills. У 2025–2026 роках AGENTS.md перетворився на центральний елемент екосистеми. Skills — ключове розширення першої половини 2026 року: рутинні операції на кшталт «прочитати Excel-файл», «згенерувати SQL» чи «провести міграцію даних» тепер збираються як конструктор Lego — готові блоки, які можна викликати за потреби. До червня 2026 року тижнева активність Codex перевищила 5 мільйонів користувачів, і 20% з них — не розробники. Цей сигнал часто ігнорують, а даремно: специфікації та інструкції для агентів більше не є справою лише інженерних команд. Їх пишуть усі — продакт-менеджери, операційники, фахівці з ризик-менеджменту (анонс OpenAI від 2 червня 2026 року; огляд thebcms.com, 2026, оцінка 0.801).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic називає проектні інструкційні документи CLAUDE.md (у лютому 2026 року вони вийшли на офіційний ринок), .claude/rules/ (правила, розподілені за каталогами) та Skills (спільні робочі процеси). Claude Code — інструмент із найвищим рівнем задоволеності розробників у першій половині 2026 року — згідно з опитуванням JetBrains 2026.1, показник CSAT становить 91%, NPS — 54, і це підтверджують два незалежні дослідження (Pragmatic Engineer, лютий 2026). Це найвищий бал у галузі AI-інструментів для програмування на сьогодні (uvik.net, травень 2026, оцінка 0,956, зведення первинних джерел). За 9 місяців Claude Code зріс із нуля до $2,5 млрд річного регулярного доходу (дані раунду G від Anthropic, лютий 2026), а на GitHub репозиторій Skills зібрав 112 тисяч зірок — розробники голосують своїми діями, і це свідчить про реальну цінність підходу, керованого правилами.

Alibaba Qoder: нормативний драйвер китайського ринку. Випущений у серпні 2025 року, 15 травня 2026 року оновлений до версії 1.0, офіційно перейшовши з «AI IDE» на «Autonomous Agent Development Workbench». Його Spec-Driven Workflow був представлений разом із Quest Mode (автономні багатофайлові завдання), Expert Mode (паралельна робота команди експертів) та RepoWiki (граф знань репозиторію). 28 травня 2026 року запущено Cloud Agents (повністю кероване середовище виконання агентів), 21 липня — Qoder Security (можливості комплаєнсу та безпеки), того ж місяця вийшла мобільна версія (Android/iOS/HarmonyOS). Станом на травень 2026 року кількість користувачів у світі перевищила 5 мільйонів, а інтеграція з Microsoft Teams CLI включила його до переліку підтримуваних середовищ виконання агентів (Yahoo Finance 2025; Alibaba Cloud official 2026; Baidu Baike 2026.7).

Спільний підхід: прямо задокументувати “як ми співпрацюємо з AI”, покласти цей документ у репозиторій і змусити всіх людей та всі AI-агенти працювати за одним і тим же стандартом. Деталі реалізації в п’ятьох платформах різняться (назви файлів / кількість етапів / механізми хук-ів), але мета абсолютно однакова.

Чому це стало масовим явищем саме в першій половині 2026 року? Тому що поріг можливостей AI вже пройдено — автономні агенти Claude Code, багатоагентний паралелізм Codex, багатофайловий рефакторинг Cursor: AI більше не “інструмент автодоповнення”, а “колега”. Документація, яку ви даєте новому колезі, має бути доступна й для AI.

III. Специфікація як рушій — це організаційна спроможність, а не вибір інструменту

Це найважливіший пункт для осіб, що ухвалюють рішення. Специфікація як рушій — це не вибір інструменту, а визначення того, “як наша організація співпрацює з AI”. Чи оберете ви GitHub Spec Kit, чи Claude Code — неважливо. Важливо, чи задокументували ви специфікацію, поклали її в репозиторій і змусили всіх людей та AI працювати за нею.

Без цього навіть найкращий інструмент лише дозволить команді швидше накопичувати борг.

Розгляньмо це в контексті масштабного впровадження у першій половині 2026 року — докази тут набагато переконливіші. У своєму ретроспективному звіті за FY26 (липень 2026) Microsoft описує кейси EY та Atos як еталонний шаблон «Frontier Firm» — не тому, що моделі нові, а тому, що обидві компанії першими дали відповідь на питання «як саме використовувати AI»:

EY: спочатку стандарти, потім масштабування. Протягом 2024–2025 років EY розгорнула Microsoft 365 Copilot для 150 000 співробітників, заощадивши 2,5 мільйона годин і близько 250 мільйонів доларів. Ключова умова — спершу створили структуру AI-управління: EY побудувала єдиний технологічний стек на базі Power Platform, Copilot Studio, Azure, Foundry та Fabric, об’єднавши нормативні вимоги, комплаєнс і аудит в одному фундаменті. Саме це дало змогу досягти 95% прискорення процесів, 37% зниження операційних витрат у фінансах і скорочення до 90% ручної роботи. Віцепрезидент EY на AI Tour 2026 висловився прямо: «Ми не спочатку впроваджували AI, а потім наздоганяли управління — ми спочатку побудували управління, а вже потім масштабували AI».

Atos: єдина площина керування для 19 000 агентів. Atos — одна з перших організацій у світі, що розгорнула Microsoft 365 E7 (Frontier Suite), охопивши Copilot для 56 000 співробітників у 54 країнах. Водночас у них працює 19 000 AI-агентів — від внутрішнього ІТ і бізнес-підрозділів до клієнтських проєктів, усі створені на базі Foundry та Copilot Studio. Ключ до успіху Atos — «єдина площина керування»: Entra (ідентифікація) + Defender (безпека) + Intune (пристрої) + Purview (відповідність) + Agent 365 (керування агентами), усі п’ять компонентів пов’язані в одне ціле. Такий підхід у фінансовому секторі відповідає концепції «багаторівневого захисту + оцінки трансферу даних + реєстрації алгоритмів + аудиту + керування моделями» — це архітектура керування, а не просто набір AI-інструментів.

Парадокс організаційних змін у Microsoft. У звіті Work Trend Index 2026 сама Microsoft визнає: “організаційні зміни відстають від індивідуального впровадження”. Серед 20 000 опитаних користувачів AI 82% керівників планують протягом 12–18 місяців розширити робочу силу за допомогою AI-агентів, але лише 24% уже завершили впровадження на корпоративному рівні. 81% керівників очікують, що AI-агенти будуть помірно або значною мірою інтегровані в AI-стратегію — і знову ж таки, лише 24% цього досягли. Це означає, що більшість компаній перебувають на відстані 12–18 місяців між “підготовкою” і “результатом”. І саме нормативне регулювання стане ключовою опорою в тому, як подолати цей розрив.

Джерела: Microsoft FY26 retrospective, 28.07.2026; Microsoft 2026 Work Trend Index Annual Report, 05.05.2026 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, первинне джерело у PDF); аналіз Futurum Group, 26.01.2026 (вторинне джерело).

Висновок перший: інвестиції в специфікації — це найвищий ROI.

Дані CodeRabbit дають чітку основу для розрахунку ROI: AI-код має приблизно в 1,7 раза більше проблем і в 2,74 раза більше вразливостей безпеки. Це означає:

  • менше повернень на доопрацювання (у фінансовій сфері один цикл комплаєнс-повернення — це 2–4 тижні);
  • менше інцидентів безпеки (один витік даних тягне регуляторні штрафи та репутаційні втрати);
  • нижчі витрати на підтримку (скорочення технічного боргу на 40% — типове число).

Написати проєктну специфікацію CLAUDE.md/AGENTS.md — це інженерна дія з найвищим ROI в епоху AI. Кейс EY дає реальне переведення в гроші: 150 000 співробітників з Copilot, економія 250 млн доларів. Зверніть увагу: EY заощадила не тому, що «інструмент був потужний», а тому, що «специфікація дозволила розкрити цінність інструменту».

Висновок другий: закріпіть специфікації в організаційних процесах, а не в головах окремих людей.

Якщо специфікації живуть лише в голові якогось досвідченого інженера, вони зникають разом з його звільненням. Їх необхідно закріпити в:

  • документації репозиторію (AGENTS.md / CLAUDE.md / constitution.md);
  • CI-гейтах (автоматична перевірка дотримання специфікацій);
  • спільних конфігураціях команди (система Skills дозволяє використовувати їх усій команді).

Зробіть специфікації організаційним активом, а не особистою навичкою. Це особливо важливо у фінансовій сфері — ваші вимоги до комплаєнсу, правила безпеки та бізнес-процедури є активами рівня організації, а не «досвідом» окремого інженера. 19 000 агентів Atos працюють у 54 країнах саме тому, що управління тут — це не «хтось знає, як треба», а «система примушує».

Висновок третій: гейтинг важливіший за швидкість.

П’ятиетапний гейтинг GitHub Spec Kit (constitution → specify → plan → tasks → implement), правило Claude Code «не писати код, поки тести не падають», вимога Kiro «не можна стартувати без spec» — усе це робить одну й ту саму річ: додає «гальма» між AI та кінцевим результатом. Кожен крок має перевірний артефакт (spec.md, plan.md, tasks.md), який можна відхилити або змінити ще до генерації коду.

Що автономніший AI, то більше він потребує гейтингу. Change Advisory Board (Change Advisory Board (CAB)) у фінансовій галузі, процедури реєстрації алгоритмів, оцінка відповідності вимогам захисту інформації (аналог європейського NIS2) — усе це, по суті, гейтинг перед запуском у продакшн. Для AI-коду потрібен аналогічний гейтинг, просто в іншій формі. Ті 62% команд зі звіту New Relic 2026, які «впевнено публікують без рев’ю», зараз розплачуються за цю самовпевненість вищим рівнем інцидентів (78%).

Три етапи впровадження стандартів у фінансовій галузі (практична версія 2026 H1) Етап 1: інвентаризація правил 2–4 тижні | найбільш затратно за часом, найвищий ROI Перелік вимог відповідності (захист рівня/виїзд/реєстрація) Правила безпеки (паролі/шифрування/логи) Бізнес-правила (ризик/транзакції/білінг) Технічні обмеження (старі API/версії) Управління постачальниками (контракти/аудит/відповідальність) Зібрати правила, розкидані по всіх місцях Упорядкувати в структурований документ Етап 2: завантажити в репозиторій 1-2 тижні | у репозиторій, AI автозавантажує CLAUDE.md / AGENTS.md constitution.md Визначення Skills (спільні робочі процеси) Дизайн гейт-процесу (п'ять етапів) .claude/rules/ (ієрархічні правила) Помістити правила в репозиторій, AI автозавантажує Етап 3: інституціоналізація Постійно | від інструменту до організаційної спроможності CI-гейт (автоперевірка) Спільна конфігурація команди (Skills) Механізм регулярного оновлення (щоквартальний огляд) Метрики (рівень дефектів / відсоток проходження комплаєнсу) Управління агентами (Agent 365 рівень 1) Стандарти стають організаційними активами, Не залежать від окремих осіб

Фаза 1 займає найбільше часу, але має найвищий ROI
Правила більшості фінансових організацій розкидані по документах/листах/головах; перше прибирання потребує 3–8 тижнів зусиль

IV. Реальне впровадження трьох етапів у першій половині 2026 року

На прикладі фінансової галузі — три етапи шляху; інші галузі з жорстким регулюванням можуть використовувати його як орієнтир. Кейси EY та Atos у першій половині 2026 року точно відповідають цим трьом етапам.

Перший етап: інвентаризація правил (2–4 тижні).

Це найбільш тривалий, але з найвищим ROI етап. Зібрати розкидані правила:

  • Комплаєнс-вимоги: для фінансової сфери мінімальний базис = ISO 27001 + Держспецзв’язку рівні H/K/C + оцінка транскордонної передачі даних + реєстрація алгоритму (якщо хоча б один з цих компонентів відсутній, краще не починати розгортати AI); крім того — правила подання звітності регулятору, захист клієнтських даних, обмеження транскордонної передачі, перелік даних, які можна показувати AI.
  • Правила безпеки: керування паролями, стандарти шифрування, обробка чутливих полів, вимоги до журналів.
  • Бізнес-правила: пороги ризик-менеджменту, умови врегулювання, торгові обмеження, логіка білінгу.
  • Технічні обмеження: інтерфейси старих систем, найменування баз даних, обмеження версій фреймворків.
  • Управління постачальниками: як вимагати від постачальників дотримання наших стандартів у контракті, як аудитувати їхнє використання AI.

Типовий сценарій: на етапі інвентаризації одна брокерська компанія виявила, що правила розкидані по численних Word-документах, вікі в JIRA, особистих листах і Excel-таблицях — лише після впорядкування вдалося отримати структурований перелік правил. Підхід Atos більш системний — вони одразу розділили правила на п’ять категорій: «комплаєнс, безпека, бізнес, технології, постачальники». Для кожної категорії створили окремий робочий процес управління, який підключили до єдиної площини керування Agent 365.

Це не технічне завдання, а організаційне — потрібно зібрати за одним столом комплаєнс, безпеку та бізнес-підрозділи й зафіксувати правила, з якими всі згодні. Перший раз це займає у фінансових організацій 3–8 тижнів — але результат стає постійним організаційним активом.

Другий етап: завантаження в репозиторій (1–2 тижні).

Правила, зібрані на першому етапі, оформлюються у вигляді документів і розміщуються в репозиторії. GitHub Spec Kit використовує constitution.md, Claude Code — CLAUDE.md, OpenAI Codex — AGENTS.md, Alibaba Qoder — Spec Workflow. Назви файлів різні, але мета одна — щоб AI завантажував їх одразу під час відкриття репозиторію.

Рекомендована структура (актуальний формат першої половини 2026 року):

  • Опис проєкту: що це за система, для кого вона створена.
  • Непорушні принципи: межі безпеки, межі комплаєнсу, межі бізнесу.
  • Технічний стек і обмеження: які фреймворки, бази даних, інтерфейси використовуються, які обмеження існують.
  • Стандарти коду: угоди про найменування, структура каталогів, мінімальні вимоги до покриття тестами (не обов’язково TDD, але потрібно чітко зафіксувати мінімальний відсоток покриття, обов’язкові шляхи тестування та заборонені шляхи — TDD це опціональний організаційний ритм, а не жорстка вимога специфікаційно-керованого підходу).
  • Бізнес-правила: правила ризик-менеджменту, торгові правила, правила білінгу.
  • Регуляторні вимоги: вимоги до захисту даних (Держспецзв’язку), оцінка транскордонної передачі, подання звітності регулятору, реєстрація AI-алгоритмів.
  • Правила використання AI: у яких сценаріях можна використовувати AI, у яких потрібна перевірка людиною, правила транскордонної передачі даних.
  • Управління постачальниками: контракти, механізми аудиту, розподіл відповідальності.

Додаток: CLAUDE.md для банку (орієнтовно 200 рядків, можна відразу форкати й адаптувати)

Нижче наведено приклад CLAUDE.md для ПриватБанку, який вже організований за принципами “нерушимі принципи → державні вимоги → навігація AI → бізнес-регули → технічні обмеження”.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
# CLAUDE.md — <назва системи> — регламент співпраці з AI

> Сфера застосування: <назва системи> v<версія>, всі AI-агенти (Claude Code / Cursor / Copilot / Codex),
> що працюють у цьому репозиторії, повинні дотримуватися цього регламенту. Документ підтримується <комітетом управління>,
> квартальний рев'ю.
> Останнє оновлення: <YYYY-MM-DD>

## 1. Огляд проєкту
- **Бізнес-призначення**: назва ядра системи / обслуговувані сегменти клієнтів / основні типи транзакцій
- **Ключовий ланцюг**: транзакція → ризик-менеджмент → кліринг → звірка → подання звітності
- **Вікно недоступності**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (будь-які зміни заборонені)
- **Основні залежності**: верхній рівень <система>, нижній рівень <система>, платформа подання звітності регулятору

## 2. Принципи, що не підлягають обговоренню (червоні лінії, порушення = відмова у злитті)

### 2.1 Червоні лінії безпеки
- Паролі, ключі, токени — обов'язково через KMS (Key Management Service), **заборонено хардкодити**, **заборонено друкувати в логах**
- Чутливі поля клієнтів (ідентифікаційний номер / номер картки / CVV / номер телефону) **повинні бути зашифровані при зберіганні**, відкритий текст у базі заборонено
- У логах заборонено: повний ідентифікаційний номер, повний номер картки, пароль у відкритому тексті, комбінація ім'я + телефон клієнта
- Зовнішні виклики API повинні проходити через API-шлюз, прямі з'єднання заборонені

### 2.2 Червоні лінії відповідності
- Якщо AI-генерований код передбачає доступ до даних клієнтів, у описі PR необхідно зазначити "доступ до даних: <поле>"
- Транскордонна передача даних заборонена, **будь-який вивіз даних потребує проходження оцінки транскордонної передачі даних** (звертатися до комплаєнс-відділу)
- Алгоритмічні рішення (кредитування / страхове ціноутворення / протидія шахрайству) повинні зберігати можливість людської перевірки
- Зміна моделі потребує реєстрації алгоритмів, номер реєстрації має бути вказаний в описі PR

### 2.3 Червоні лінії бізнесу
- Зміна порогів ризик-менеджменту потребує двох підписів: керівника ризиків і керівника бізнесу
- Операції з коштами клієнтів повинні мати ідемпотентність + відкат у разі збою
- Зміна лімітів транзакцій, тарифів і параметрів продукту здійснюється через платформу управління параметрами, хардкодження в коді заборонено

## 3. Технологічний стек та обмеження
- **Мови**: Java 17 (ядро) / Kotlin (нові модулі) / SQL (база даних)
- **Фреймворк**: Spring Boot 3.x + Spring Cloud Alibaba
- **База даних**: OceanBase 4.x (режим сумісності з MySQL), **використання зовнішніх ключів заборонено**
- **Стандарти інтерфейсів**: внутрішні — gRPC; зовнішні — OpenAPI 3.0; RESTful лише для адміністративних інтерфейсів
- **Угоди найменування**: класи Java — PascalCase, методи — camelCase, константи — UPPER_SNAKE; назви таблиць `t_<бізнес-домен>_<сутність>`; індекси `idx_<таблиця>_<поле>_<порядок>`
- **Структура пакетів**: `com.<компанія>.<бізнес-домен>.<піддомен>.<рівень>` (наприклад, `com.bank.pay.tx.core.service`)

## 4. Стандарти коду
- **Мінімальне покриття тестами**: ключовий ланцюг ≥ 80%, утиліти ≥ 60%, новий код у PR має супроводжуватися тестами
- **Обов'язкові шляхи тестування**: всі controller повинні мати інтеграційні тести (включаючи шляхи відмови); всі гілки enum повинні мати юніт-тести
- **Заборонені шляхи**: заборонено модифікувати каталог `<модулі історичної спадщини>` — спочатку створіть адаптаційний шар
- **Керування залежностями**: нові сторонні залежності потребують SCA-сканування + погодження безпеки

## 5. Бізнес-правила (за доменами)
### 5.1 Транзакції
- Ліміт однієї операції: <сума>; добовий ліміт: <сума>; перевищення — ручне затвердження
- Вікно транзакцій: <HH:MM> ~ <HH:MM>
- Визначення дублікату транзакції: у межах <часового вікна> однакове <поле> = дублікат

### 5.2 Ризик-менеджмент
- Пріоритет чорного списку: внутрішній чорний список → регуляторний спадний список → судове замороження
- Поріг виходу моделі протидії шахрайству: <оцінка>; перевищення — обов'язкова друга ручна перевірка

### 5.3 Білінг
- Зміна тарифу повинна мати номер версії + дату набрання чинності
- Історичні замовлення розраховуються за тарифом, що діяв на дату набрання чинності, без ретроактивного перерахунку

## 6. Вимоги відповідності
- MLPS рівень 3: <орган оцінки>, <дата наступної оцінки>
- Оцінка транскордонної передачі даних: сфера застосування (лише модулі транскордонної діяльності)
- Реєстрація алгоритмів: сфера застосування (кредитування / страхове ціноутворення тощо), номер реєстрації <номер реєстрації>
- Регуляторна звітність: таблиця відповідності полів <регулятор (CBIRC / Народний банк Китаю)> знаходиться у <шлях>

## 7. Стандарти використання ШІ
- **Сценарії, де ШІ дозволено**: CRUD-шаблони, генерація юніт-тестів, чернетки документації, рекомендації з оптимізації SQL
- **Сценарії, що потребують обов'язкової ручної перевірки**: логіка ризик-менеджменту, правила білінгу, контроль доступу, шифрування/дешифрування, транскордонні дані
- **Сценарії, де ШІ заборонено діяти самостійно**: матеріали для затвердження Change Advisory Board (CAB) (Change Advisory Board), виконання змін у прод, аварійне реагування
- **Правила вивезення даних**: навчальні дані / промпти / логи виводу — вивезення заборонено; перевага надається локалізованим версіям розгортання (<постачальник>)
- **Вимоги до аудиту**: весь AI-генерований код має бути позначений в описі PR як "AI-допомога: <назва інструменту>"

## 8. Управління постачальниками
- **Допуск постачальників**: вимагати звіти SOC 2 / ISO 27001; AI-моделі повинні супроводжуватися model card
- **Контрактні умови**: право власності на дані, пояснюваність моделі, умови виходу, право аудиту
- **Механізм аудиту**: квартальний аудит використання AI постачальниками; для високоризикових постачальників — щомісячний аудит

## 9. Управління та оновлення
- **Власник**: <комітет управління> (комплаєнс + безпека + архітектура + бізнес)
- **Частота оновлень**: квартальний рев'ю; екстрені зміни — через швидкий канал (дві підписи + 24h публікація)
- **Журнал змін**: див. `CLAUDE_CHANGELOG.md`
- **Обробка порушень**: перше порушення = попередження + примусове навчання; друге = призупинення використання AI-інструментів; третє = скасування прав

Цей матеріал не є стандартним відповідем, а скоріше заповнювальним шаблоном. Що саме заповнити в кожній порожній клітинці, важливіше, ніж кількість написаних слів. Порожні місця розкривають ті частини компанії, які ще не були сплановані.

Наприклад, у деяких банках вже існує спеціальний документ CLAUDE.md, де визначені правила обробки паролів. Коли AI-генерований код стосується паролів, він повинен викликати внутрішній API керування паролями, а не використовувати закодовані дані. Такі правила часто стають причиною відмови в перевірці відповідності вимогам.

У першому півріччі 2026 року новим важливим полем стає Навички/Визначення робочого процесу. Це не лише документація, а й інструментальна ланцюжок, який можна викликати AI. Система Skills від Claude Code (яка вже була представлена в офіційному магазині Anthropic у лютому 2026 року та має понад 112 тисяч зірок на GitHub) перетворює такі завдання, як “читання таблиць Excel”, “генерування SQL” або “робота з міграцією даних” на спільні робочі процеси. Цей розвиток є ключовим кроком у розвитку 2026 року: Норми не лише обмежують, а й виконуються як робочі процеси.

Третій етап: інституціалізація (постійність)

Установлення правил не закінчуєся цим. Ви повинні зробити їх частиною організаційних процесів:

  • CI-governance: автоматично перевірте, чи дотримуються коду правила (наприклад, перевірте, чи немає зашифрованих паролів чи відкритих даних).
  • загальна конфігурація команди: використовуйте систему Skills, щоб усі члени команди могли працювати з однією і тією ж конфігурацією правил.
  • система періодичної оновлення: якщо правила змінилися, конфігурація правил повинна змінитися разом з ними (квартальні огляди).
  • визначення та відгук: слідкувати за кількістю помилок в коді AI, кількістю успішних перевірок відповідності, кількістю повторної роботи.
  • Управління агентами: розширити управління людьми на управління AI-агентами — Atos реалізував це на Agent 365, зробивши це «системним» рівнем, а не особистим.

EY та Atos у першому півріччі 2026 року перетворили третій етап на «організаційну спроможність». 2,5 мільйона годин економії EY — це результат правильно реалізованих першого та третього етапів; другий етап був лише перекладом правил на мову, яку може прочитати AI.

V. Варіанти для жорстко регульованих галузей: три інженерні підходи до інтеграції комплаєнсу

Фінансові, телекомунікаційні та медичні галузі зі строгими регулюваннями мають додаткову стадію — відповідність не є зовнішнім додатком процесу, а є інтегрованим у код. Нижче наведені три методи інтеграції відповідності, які були перевірені у першому півріччі 2026 року, і керівники IT/директори цифрового розвитку можуть використовувати їх у своїй організації.

5.1 Впровадження співробітників з питань дотримання в потоці розробки: зробити дотримання присутнім, а не затвердженим

Традиційний підхід: бізнесові команди пишуть код, а команди з питань дотримання перевіряють його пізніше. Коли проблеми виявляються, код вже був випущений протягом півмісяця, а вартість повернення до розробки становить 2-4 тижні. Питання полягає в тому, що дотримання знаходиться в кінці процесу.

Новий підхід: в кожній команді розробників потоку (stream-aligned team) розміщувати співробітника з питань дотримання. Форма цього співробітника є “прямою лінією в відділі дотримання, а лінією зірок в бізнес-команді”. Конкретні вимоги:

  • Персональний склад: співробітника з питань дотримання розміщувати кожні 6-8 команд розробників, підпорядковувати відділу дотримання, фізично розміщувати в бізнес-команді - не на дистанційній основі.
  • Віртуальні КПІ: співробітника з питань дотримання оцінювати з вагою 50% щодо бізнес-команди за “рівнем дотримання” та “рівнем затвердження в першому проході”, а не лише за рівнем затвердження відділу дотримання.
  • Передчасовий втручання: співробітника з питань дотримання залучати до щоденних засідань команди розробників (щотижня достатньо), перевірки Pull Request, а також перевірки коду, згенерованого AI, перед його злиттям - а не після.
  • Навчальні засоби: співробітника з питань дотримання використовувати інструменти перевірки дотримання, такі як Skills, а не здійснювати перевірку вручну.

Типовий сценарій: один із національних акціонерних банків у першому півріччі 2026 року запустив пілот із трьома потоковими командами, до яких було вбудовано комплаєнс-представників. У результаті частка відхилених AI-кодів у межах комплаєнс-перевірки знизилася з 35% до 8% — і ключ тут не в тому, що комплаєнс став «суворішим», а в тому, що він став «ранішим». Головна умова такого підходу — щоб непряма мотивація комплаєнс-представників була узгоджена з бізнес-цілями — якщо KPI комплаєнс-представника досі визначаються лише завданнями від комплаєнс-департаменту, таке вбудовування приречене на провал.

5.2 Комплаєнс як enabling team: перетворити обмеження на можливості

Традиційний підхід: комплаєнс-команда виконує роль «вартового», а бізнес-команди сприймають комплаєнс як «джерело проблем». У результаті — гра з нульовою сумою.

Новий підхід: комплаєнс-команда перебудовується за моделлю enabling team з Team Topologies — вона не пише код напряму, не рев’ює pull request-и, але надає три речі, які дозволяють бізнес-командам «проходити комплаєнс самостійно»:

  1. Перевірки комплаєнсу в CI-конвеєрі: перетворити типові комплаєнс-точки (зашифровані паролі, відкриті чутливі поля, транскордонна передача даних, точки алгоритмічних рішень) на примусові гейти через GitHub Actions / GitLab CI. PR бізнес-команд запускає автоматичну перевірку, невідповідність одразу fail — без потреби в ручному прогоні комплаєнс-представника.

  2. Регуляторні вимоги як affordance (середовище реагує): наприклад, під час розробки функцій, що працюють із клієнтськими даними, плагін IDE виводить підказку «для цього поля рекомендовано викликати KMS»; під час написання логів автоматично виявляється наявність чутливої інформації та спрацьовує попередження. Регуляторні вимоги стають «природною дією під час розробки», а не «повідомленням про порушення перед релізом».

  3. Спільна бібліотека Skills + навчання комплаєнсу: комплаєнс-команда підтримує набір «комплаєнс-Skills», до яких звертаються під час онбордингу нових співробітників або переходу між командами — комплаєнс-знання перетворюються з «документа» на «інструмент, який можна виконати».

Типовий сценарій: один міський банк у першій половині 2026 року запустив CI-гейти для комплаєнсу + IDE-підказки щодо комплаєнсу, скоротивши середній час комплаєнс-перевірки AI-коду з 45 хвилин на справу до 8 хвилин на справу, ключ не в тому, що комплаєнс «перевіряє швидше», а в тому, що AI одразу «не помиляється» під час генерації.

5.3 Двошвидкісний комплаєнс: шарове узгодження з бізнес-ритмом

Остання деталь: комплаєнс не має бути «一刀切». Правила слід розділити на два рівні за ризиком:

  • Високоризикові правила (стосуються коштів клієнтів / алгоритмічних рішень / транскордонних даних / червоних ліній захисту рівня) ідуть через суворий гейт: обов’язковий ручний рев’ю + повторне підтвердження AI + реєстрація в Change Advisory Board (CAB)
  • Низькоризикові правила (CRUD-шаблони / утилітний код / генерація документації) ідуть через самообслуговуючий гейт: достатньо автоматичної CI-перевірки, ручне рев’ю не потрібне

Контрольна площина Agent 365 від Atos по суті реалізує саме це шарування — різні рівні агентів прив’язані до різних вимог управління. Коли правила комплаєнсу розділені за ризиком, бізнес-команди відчувають, що «комплаєнс не блокує мене на кожному кроці».

Спільний висновок цих трьох підходів: вбудовування комплаєнсу — це не додавання ще одного процесу, а перепроєктування структури й мотивації потокових команд. Якщо ваш комплаєнс-відділ і далі працює в режимі «пост-аудиту», нормативно-орієнтований підхід застрягне на найскладнішому етапі — «інституціоналізації» — комплаєнс-відділ має трансформуватися першим, інакше нормативно-орієнтований підхід у бізнес-командах не запуститься.

VI. Запитання, які ви могли б поставити

“Ми вже маємо кодові стандарти, а що відрізняє цей підхід?”

Кодові стандарти регулюють “Як писати код”, а нормативно-орієнтований підхід регулює “Як співпрацювати з AI”. Кодові стандарти не містять: бізнес-регламентів, вимог щодо дотримання законодавства, стратегії використання AI. Нормативно-орієнтований підхід робить “Всю діяльність людини і AI явною”, а не є керівництвом щодо стилю коду.

“Чи сповільнить написання специфікацій розробку?”

У короткостроковій перспективі — так, у довгостроковій — ні. Дані CodeRabbit дають чітку відповідь: код, згенерований AI без жодних обмежень, має приблизно в 1,7 раза вищий ризик дефектів і в 2,74 раза вищий ризик уразливостей безпеки. У фінансовому секторі один цикл доопрацювання через комплаєнс-перевірку коштує 2–4 тижні — і одного уникненого циклу достатньо, щоб окупити місяць роботи над специфікаціями. Економія $250 млн, яку зафіксувала EY, — це реальний доказ того, що такий підхід можна перетворити на організаційну спроможність.

“А якщо в нашій команді ніхто не вміє писати специфікації?”

Починати з нуля не доведеться. У GitHub Spec Kit, Claude Code Superpowers та AWS Kiro вже є готові шаблони. Вам лишається лише додати правила, специфічні для вашої організації — здебільшого це комплаєнс- і безпекові вимоги, які ваші відповідні відділи вже давно сформулювали. Просто вони досі не були в місці, доступному для AI.

“Інструментів на базі AI багато — який обрати?”

Неважливо. Беріть те, що вже використовуєте. Підхід на основі правил не прив’язаний до інструменту — CLAUDE.md працює і в Claude Code, і в Cursor, і в Codex; AGENTS.md запускається в екосистемі OpenAI; constitution.md взагалі не залежить від моделі. Головне — писати правила, а не міняти інструменти. EY розгортає це в екосистемі Microsoft, Atos — теж в екосистемі Microsoft. Різниця у виборі інструментів — лише зовнішня; уніфікована структура governance — ось що справді має значення.

«У серпні 2026 року EU AI Act набуває повної чинності. Чи вплине це на нас?»

Так. EU AI Act набуває повної чинності 2 серпня 2026 року і встановлює обов’язкові вимоги для високоризикових систем ШІ — включно з кредитуванням, страховим ціноутворенням, відбором кандидатів на роботу та критичною інфраструктурою. Йдеться про управління ризиками (ст. 9), якість даних (ст. 10), прозорість документації (ст. 11–13), людський нагляд (ст. 14) та точність/надійність (ст. 15). Штрафи сягають 35 млн євро або 7% глобального обороту. Для китайських компаній, що виходять на ринок ЄС, це обов’язкова тема. А для внутрішнього ринку — EU AI Act фактично став найбільш референтним стандартом у світі: навіть якщо ви не підпадаєте під нього напряму, його вплив через постачальників, партнерів і транскордонні операції обійти практично неможливо (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

«А що в нас? Китайський підхід: не сам ШІ, а його використання»

У Китаї регулювання генеративного ШІ будується на трьох опорах: реєстрація алгоритмів, перевірка навчальних даних і оцінка безпеки. Ключовий документ — «Тимчасові заходи щодо управління послугами генеративного штучного інтелекту», що діють із серпня 2023 року. В Україні регуляторне поле формується «Мінцифра AI регуляторним проєктом» (2024) на основі ЗУ № 2297-VI (2010, з новим проєктом 12277/2024, що гармонізується з GDPR). Головна відмінність від європейського підходу не в деталізації норм, а в самій філософії законодавства:

Що відрізняє законодавство щодо штучного інтелекту в ЄС та Китаї?

ПараметрЄС (Акт про штучний інтелект)Китай (Порядок управління послугами штучного інтелекту)
Положення законодавстваХоризонтальне регулювання (застосовується до всіх систем штучного інтелекту)Вертикальні правила (зосереджені на послугах штучного інтелекту)
Рівні ризику4 рівні (невідповідність / високий / обмежений / дуже малий)2 рівні (відносно безпеки громадськості / загальне використання)
Точка регулюванняПередбачена (розробка передбачає реєстрацію)Після виходу на лід (послуга реєструється після виходу на лід + реєстрація алгоритму)
ПрозорістьВисока (обов’язково публікувати підсумковий виклад джерел навчання, модельні карти)Середня (обов’язково дотримуватися вимог щодо матеріалів навчання, але не обов’язково публікувати джерела)
Порогові штрафи7% світових продажів або 35 мільйонів євроВідключення послуги / штраф (зазвичай в кілька разів більший за отриманий прибуток)
Діапазон застосуванняВсі підприємства, які перевищують світові пороги продажівВсі суб’єкти, які здійснюють послуги в Китаї

На практиці внутрішні фінансові системи в Китаї одночасно підпадають під дію трьох регуляторних шарів: «Правила управління генеративним AI» (базовий рівень) + «Правила управління інтернет-кредитами для комерційних банків» (бізнес-рівень) + вимоги захисту інформації та реєстрації алгоритмів (рівень комплаєнсу). Це означає, що в Китаї специфікаційно-керований підхід не може бути реалізовано простим копіюванням європейської рамки EU AI Act. Натомість у проєктну специфікацію необхідно включити всі три рівні регулювання: «цілісність даних + реєстрація алгоритмів + подання звітності регулятору».

Для українських експортерів на ринок ЄС: європейський підхід EU AI Act уже сьогодні є орієнтиром, який Україна імплементує через проєкт Мінцифри. Якщо ви зараз пишете специфікацію, сумісну з EU AI Act, протягом найближчих 3 років вона з високою ймовірністю лишатиметься сумісною і з українськими регуляторними оновленнями, включно з гармонізацією проєкту 12277/2024 до GDPR (реєстраційні повідомлення Мінцифри та повідомлення про реєстрацію китайських регуляторів за 2025–2026 роки; EU AI Act compliance 2026.6).

VII. Висновки для осіб, що ухвалюють рішення

Висновок 1: написати проєктну специфікацію CLAUDE.md/AGENTS.md — це інженерна дія з найвищим ROI в епоху AI.

Його вкладення — це 3–8 тижнів інвентаризації + 1–2 тижні оформлення документа. Його віддача: верхня межа ризику дефектів — близько 1,7 раза, скорочення вразливостей безпеки — у 2,74 раза, падіння частки повернень на доопрацювання — на 40%+. У фінансовій сфері економія на одному комплаєнс-поверненні (2–4 тижні) покриває цю вартість. EY розгорнула Copilot для 150 000 співробітників і заощадила 250 млн доларів — але спершу маючи специфікацію.

Висновок 2: нормативна база — це організаційна спроможність, а не вибір інструменту.

Неважливо, оберете ви GitHub Spec Kit чи Claude Code. Важливо, чи визначили ви, «як наша організація співпрацює з AI». Без цього навіть найкращий інструмент лише дозволить команді швидше накопичувати борг.

Висновок 3: фіксуйте нормативи в організаційних процесах, а не покладайтеся на окремих людей.

Якщо нормативи існують лише в голові досвідченого інженера, вони зникнуть разом із плинністю кадрів. Їх необхідно закріпити в документації репозиторію, CI-гейтах, спільних конфігураціях команди та платформах керування агентами. Нормативи мають стати організаційним активом, а не особистою навичкою. 19 000 агентів Atos працюють у 54 країнах саме тому, що управління — це не «хтось розуміє», а «система зобов’язує».

Висновок 4: гейти важливіші за швидкість.

П’ятиетапний гейтинг GitHub Spec Kit, правило Superpowers «не писати код, поки тести не падають», вимога Kiro «не можна стартувати без spec» — усе це додає «гальма» між AI та кінцевим результатом. Що потужніший AI, то більше управління має випереджати його. Ті 78% рівня інцидентів зі звіту New Relic 2026 — це ціна, яку сплачують 62% команд, що «публікують без рев’ю». CIO у фінансовій сфері знають це краще за всіх: їхні Change Advisory Board (Change Advisory Board (CAB)), процедури реєстрації алгоритмів та оцінка відповідності вимогам Держспецзв’язку — усе це гейтинг перед випуском у продакшн. AI-код потребує аналогічного гейтингу, причому ще більш випереджаючого.

Зворотна самоперевірка (відповідайте чесно, без прикрашання): ваш AI-генерований код — чи часто його повертають із комплаєнс-перевірки? Яка остання проблема, спричинена AI-кодом? Якщо ви запитаєте технічного керівника «як ми співпрацюємо з AI» — чи зможе він/вона показати документ? Якщо на якесь із цих трьох питань немає відповіді — специфікаційно-керований підхід ще не працює — спершу пишіть специфікації, а вже потім купуйте інструменти.

Три коучингові запитання для осіб, що ухвалюють рішення

На завершення — три запитання, не чек-ліст, а інструмент для обговорення з вашою командою:

  1. “Якщо завтра всі AI-інструменти зникнуть, наскільки впаде якість коду вашої команди?” — Це питання розкриває справжню цінність специфікацій: якщо відповідь “суттєво впаде” — ваші специфікації ще не усталені; якщо “майже не зміниться” — специфікації вже працюють на вас.
  2. “У вашому проєкті зі специфікаціями комплаєнс-відділ — це ‘брама’ чи ‘енabler’?” — Якщо “брама”, ваша швидкість впровадження впертиметься в бюрократичні затори; якщо “енabler” — ви вже на правильному шляху, описаному в розділі 5.2.
  3. “Через 12–18 місяців як зміниться розмір вашої команди?” — За даними Microsoft WTI 2026, 82% керівників планують “розширювати” робочу силу за допомогою AI-агентів. Якщо ваша відповідь “не зміниться”, або ваш бізнес не зростає, або ваша організаційна структура не встигає за перевагами специфікацій.

На ці три питання немає єдиної правильної відповіді. Але напрямок відповіді важливіший за саму відповідь.

Що далі

Це шостий матеріал із серії “Трансформація розробки ПЗ в епоху AI”. Ми пройшли шлях від Конвея (організація визначає архітектуру) через Team Topologies (як проєктувати організацію) до зміщення вузького місця (воно тепер у валідації, а не в написанні коду). Сьогодні ми говоримо про специфікації (використання документації для обмеження поведінки AI).

У наступній (сьомій) частині ми розглянемо базову інфраструктуру, на якій усе це тримається — протокол MCP (Model Context Protocol): чому відкритий протокол від Anthropic називають «USB-C для ШІ», чому OpenAI, Google і Microsoft усі приєдналися до нього, і як він уможливлює взаємодію між багатьма інструментами та агентами.

Хочете впровадити цей підхід у своїй компанії?

Коли нормативно-орієнтований підхід потрапляє в реальну організацію, на практиці зазвичай постають кілька конкретних питань: як закріпити ключові правила у файлах CLAUDE.md / AGENTS.md, як привести наявний код до стандартів, як вбудувати комплаєнс і за якими метриками оцінювати пілотний проєкт.

Наразі пропонуємо три формати співпраці:

  • Корпоративне навчання: на основі реальних проєктів вашої компанії — розробка нормативних документів, проєктування CI-гейтів, шляхів упровадження комплаєнсу та побудова механізмів управління.
  • Цільовий консалтинг: фокус на одному чіткому рішенні, наприклад, «чи варто нам спочатку писати CLAUDE.md / AGENTS.md» або визначення пріоритетів приведення наявного коду до вимог.
  • Виступи для керівництва та галузеві доповіді: теми ШІ-інструментів для програмування, нормативно-орієнтованого підходу, організаційного управління та Frontier Firms.

Стаття пропонує загальну рамку, але практичне впровадження потребує переосмислення з урахуванням комплаєнс-вимог компанії, регуляторних меж, інженерної зрілості та наявних процесів доставки. Для співпраці звертайтеся: coach@iaiuse.com.

Додатково: «Методологія знаків v1.0» (Повільно вчимо AI, випуск 187) — системний огляд 7-крокової рамки трансформації ШІ в підприємствах.

Про цю серію

«Трансформація інженерії програмного забезпечення в епоху ШІ» — це дослідницька серія для CIO, CDO, CTO та керівників цифрової трансформації в телекомунікаціях, фінансах, виробництві та електронній комерції. Серія налічує 18 статей і зосереджена на тому, як AI-інструменти для програмування, нормативно-орієнтований підхід та організаційне управління впливають на процеси доставки програмного забезпечення, організаційну структуру та інженерну зрілість.

Ми постійно відстежуємо академічні публікації, матеріали вендорів та галузеві звіти. Дослідницька база налічує понад 200 джерел. Для ключових висновків ми зазначаємо рівень доказовості, розрізняючи підтверджені факти, заяви вендорів, галузеві спостереження та авторські припущення.

Я маю майже 8 років досвіду в консалтингу та бізнес-аналізі для великих підприємств, зокрема працював в IBM над проєктами в телекомунікаціях, фінансах, страхуванні та виробництві. Згодом продовжив працювати на передовій розробки операторських продуктів, інтернет-продуктів та AI-застосунків, займаючись аналізом вимог, продуктовим дизайном і впровадженням у міжкомандній взаємодії.

Судження цієї серії про специфікації як рушійну силу, організаційне управління та інженерну зрілість базуються на цих практиках і додатково перехресно перевіряються відкритими дослідженнями та галузевими кейсами. Усі згадки конкретних проєктів знеособлено; частина галузевих сценаріїв належить до типових проблемних траєкторій, відповідні підстави наведено в розділі джерел.

За цим блогом стоїть невелика команда — я та 1–2 колеги, з якими миппрацюємо давно; ми розподіляємо між собою дослідження AI-інструментів для програмування, опрацювання кейсів з організаційного управління та коучингові діалоги. Більшість проєктів, про які йдеться у статтях як «ті, що ми пройшли з компаніями», ми реалізували спільно. Імена клієнтів і межі їхнього комплаєнсу свідомо не розкриваються — анонімність залишається простором для майбутніх колег-партнерів.

Джерела (усі перевірено, для кожного позичення зазначено рівень доказовості)

  • CodeRabbit (2025.12). State of AI vs Human Code Generation Report. Проблем в AI-коді в 1,7 раза більше, ніж у коді, написаному людиною (10,83 проти 6,45 проблеми на PR), логіка/коректність — у 1,75 раза, якість коду — у 1,64 раза, безпека — у 1,57 раза, обробка паролів — у 1,88 раза, XSS — у 2,74 раза. Рівень доказовості: перший. Джерело: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263

  • The Register (2025.12.17). Висвітлення повного звіту CodeRabbit: аналіз 470 відкритих PR-запитів, PR з AI-співавторством містять 10,83 проблеми проти 6,45 у суто ручних. Рівень доказовості: другий. Джерело: та сама URL-адреса

  • CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap” — 2026 рік стає переломним моментом переходу від «швидкості генерації коду» до «якості коду та керування ним». Рівень доказовості: другий. Джерело: https://tfir.io/ai-code-quality-2026-guardrails

  • New Relic (2026). The 2026 State of AI Coding Report. 78% команд повідомляють про більше інцидентів після впровадження AI-коду; 62% технічних лідерів визнають, що їхні команди «впевнено публікують код без перевірки»; 96% вважають спостережуваність обов’язковою. Рівень доказовості: перший (звіт вендора). Джерело: https://newrelic.com/resources/report/2026-state-of-ai-coding

  • Microsoft 2026 Work Trend Index Annual Report (2026.5.5). Опитування 20 000 працівників, які використовують AI, у 10 країнах; 82% керівників планують протягом 12–18 місяців розширити робочу силу за допомогою AI-агентів; 81% очікують помірної або значної інтеграції AI-агентів; 24% уже впровадили їх на корпоративному рівні; 49% діалогів у Copilot підтримують когнітивну роботу; 58% користувачів AI кажуть, що роблять речі, які були неможливі рік тому, а серед Frontier Professionals цей показник сягає 80%. Рівень доказовості: перший. Джерело: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf

  • Microsoft FY26 Підсумки: від AI-експериментів до трансформації на рівні фронтиру (28.07.2026). EY розгорнула Microsoft 365 Copilot для 150 000 співробітників, заощадивши 2,5 мільйона годин і близько 250 мільйонів доларів; масштабування на 400 000 працівників по всьому світу дало прискорення роботи на 95%, зниження фінансових операційних витрат на 37% і скорочення до 90% ручних робочих процесів. Atos розгорнула Copilot для 56 000 співробітників у 56 країнах, а також 19 000 AI-агентів, з уніфікованою площиною керування для ідентичності, безпеки, комплаєнсу та governance. Рівень доказовості: перший (офіційний огляд Microsoft). Джерело: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Стратегічна співпраця Atos Group і Microsoft (2026.6.9). Atos впроваджує Microsoft 365 E7 (Frontier Suite) для 56 000 співробітників у 56 країнах + 19 000 AI-агентів; уніфікована площина керування Entra/Defender/Intune/Purview/Agent 365. Рівень доказовості: перший (спільний пресреліз обох компаній). Джерело: 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 (відкрито у вересні 2025, розвиток у 1H 2026). 5-етапний процес з воротами /speckit.constitution → /specify → /plan → /tasks → /implement, плюс /clarify /analyze; не залежить від моделі (працює з Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code). Рівень доказовості: перший. Джерело: https://github.com/github/spec-kit

  • AWS Kiro (випущено у липні 2025, розвиток у 1H 2026). Триетапний робочий процес: вимоги → дизайн → завдання; spec тригеріть попередньо визначені дії агента; без написання spec робота не запускається. Рівень доказовості: перший. Джерело: https://kiro.dev/

  • OpenAI Codex + AGENTS.md + Skills (2025-2026). Codex 2026.6 — понад 5 млн щотижневих активних користувачів, 20% з них — не розробники; AGENTS.md + Skills як комбінований набір інструкцій. Рівень доказовості: перший (офіційні оголошення OpenAI). Джерело: https://developers.openai.com/codex/skills

  • Claude Code (Anthropic, перша половина 2026). Система CLAUDE.md + .claude/rules/ + Skills; у лютому 2026 потрапив в офіційний маркетплейс Anthropic; репозиторій Skills на GitHub — 112 тисяч зірок; у лютому 2026 під час раунду G розкрито річний дохід у 2,5 млрд доларів. Рівень доказовості: перший. Джерело: https://code.claude.com/docs/en/claude-directory

  • JetBrains AI Pulse Survey (2026.1). Опитування понад 10 000 професійних розробників у всьому світі, локалізоване 8 мовами; CSAT для Claude Code — 91%, NPS — 54 (найвищий показник у галузі); рівень впровадження Claude Code на робочих місцях — 18% (зріс у 6 разів із 3% за 9 місяців), у Північній Америці — 24%; Copilot — 29% впровадження на робочих місцях, але зростання зупинилося; Cursor — 18%. Рівень доказовості: перший. Джерело: https://www.jetbrains.com/lp/tools/ai-tools/

  • Pragmatic Engineer Newsletter (2026.2). Опитування 15 000 розробників; 46% обрали Claude Code як «найулюбленіший інструмент», Cursor — 19%, Copilot — 9%. Рівень доказовості: перший. Джерело: https://newsletter.pragmaticengineer.com/

  • Alibaba Qoder (2025.8 → 2026.7). У серпні 2025 року Alibaba випустила Qoder; 15 травня 2026 року Qoder 1.0 оновлено до Autonomous Agent Development Workbench; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; 28 травня 2026 року — Cloud Agents (кероване середовище виконання агентів); 21 липня 2026 року — Qoder Security; у травні 2026 року — понад 5 мільйонів користувачів у світі; інтеграція з Microsoft Teams CLI; 20 травня 2026 року Tongyi Lima перейменовано на Qoder CN. Рівень доказовості: перший. Джерела: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525

  • vibecoding.app / thebcms.com / tfir.io (перша половина 2026). Команди п’яти етапів Spec Kit, порівняльний огляд інструментів SDD, нотація EARS. Рівень доказовості: другий (сторонні огляди). Джерела: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development

  • EU AI Act / Code of Practice (повне застосування з 2 серпня 2026). Для високоризикових AI-систем дедлайн відповідності — 2 серпня 2026; для наявних GPAI-моделей — до 2 серпня 2027; штрафи — до 35 млн євро або 7% глобального обороту; Art. 9–15: управління ризиками, керування даними, прозорість документації, людський нагляд, точність і надійність. Рівень доказовості: перший (регламент + вторинний комплаєнс-аналіз). Джерела: 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). 44% проблем у коді спричинені браком контексту. Рівень доказовості: другий (звіт вендора). Джерело: https://www.qodo.ai/reports/state-of-ai-code-quality/

]]> AI-код має в 1,7 раза більше проблем і в 2,74 раза більше вразливостей — бо AI не бачить ваші правила. У 2026 H1 п'ять платформ переходять на специфікації. 【Spec-Driven Development】การเขียนสเปกคือการลงทุนด้านวิศวกรรมที่ให้ ROI สูงสุดในยุค AI — วิวัฒนาการวิศวกรรมซอฟต์แวร์ยุค AI — 慢慢学AI177 https://iaiuse.com/th/posts/spec-driven-development-%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B9%80%E0%B8%82%E0%B8%B5%E0%B8%A2%E0%B8%99%E0%B8%AA%E0%B9%80%E0%B8%9B%E0%B8%84%E0%B8%84%E0%B8%B7%E0%B8%AD%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%A5%E0%B8%87%E0%B8%97%E0%B8%B8%E0%B8%99%E0%B8%97%E0%B8%B5%E0%B9%88%E0%B8%84%E0%B8%B8%E0%B9%89%E0%B8%A1%E0%B8%84%E0%B9%88%E0%B8%B2%E0%B8%97%E0%B8%B5%E0%B9%88%E0%B8%AA%E0%B8%B8%E0%B8%94%E0%B9%83%E0%B8%99%E0%B8%A2%E0%B8%B8%E0%B8%84ai-%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B9%80%E0%B8%9B%E0%B8%A5%E0%B8%B5%E0%B9%88%E0%B8%A2%E0%B8%99%E0%B9%81%E0%B8%9B%E0%B8%A5 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z

ข้อมูลในบทความอ้างอิงจาก: รายงาน CodeRabbit 2025.12 / New Relic 2026, Microsoft Work Trend Index 2026, ประกาศ Microsoft FY26 Frontier Firms, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, และ JetBrains 2026.1 AI Pulse กรณีศึกษาที่นำเสนอเป็นภาพรวมของสถานการณ์ทั่วไป ไม่ได้ชี้เฉพาะองค์กรใดองค์กรหนึ่ง

ความผิดพลาดครั้งใหญ่ที่สุดของคุณไม่ใช่การไม่ซื้อเครื่องมือ แต่คือการไม่เขียน CLAUDE.md

CIO ของธนาคารพาณิชย์แห่งหนึ่งบ่นกับผมว่า ซื้อเครื่องมือ AI แล้ว deploy โมเดลแล้ว อบรมพนักงานแล้ว แต่ครึ่งปีแรกของปี 2026 ระยะเวลาการส่งมอบงานแทบไม่ขยับเลย หัวหน้าทีมระบบหลักพูดตรงๆ ว่า “โค้ดที่ AI เขียนใช้ได้จริง แต่ต้องมาเขียนใหม่ทุกครั้ง เพราะมันไม่เข้าใจกฎของธนาคารเรา ไม่เข้าใจข้อกำหนดด้านกำกับดูแล และไม่รู้วิธีเชื่อมต่อกับระบบเก่าอายุ 30 ปีของเรา”

ปัญหาที่แท้จริงไม่ใช่เพราะ AI เก่งไม่พอ แต่เพราะคุณไม่ได้เขียนกติกาไว้ต่างหาก การวิเคราะห์ pull request แบบ open source จำนวน 470 รายการโดย CodeRabbit ในเดือนธันวาคม 2025 ให้ตัวเลขที่ถูกอ้างอิงอย่างกว้างขวาง: PR ที่เขียนร่วมกับ AI มีปัญหาเฉลี่ย 10.83 จุด ขณะที่ PR ที่เขียนโดยมนุษย์ล้วนมี 6.45 จุด——1.7 เท่า กล่าวคือมีบั๊กมากกว่าที่เขียนโดยมนุษย์ถึง 70% พอมาถึงปี 2026 เรื่องราวก็ยังไม่พลิกกลับ: New Relic พบใน 2026 State of AI Coding Report ว่า 78% ของทีมรายงานเหตุการณ์ผิดปกติเพิ่มขึ้นหลังนำโค้ดที่เขียนโดย AI ขึ้นสู่ระบบจริง และ 62% ของผู้บริหารสายเทคนิคยอมรับว่าทีมของตน “มั่นใจเกินไปที่จะส่งโค้ด AI ขึ้น production โดยไม่ตรวจทีละบรรทัด” (รายงานทางการของ New Relic ปี 2026, คะแนน 0.866, แหล่งข้อมูลระดับปฐมภูมิ) ตัวเลขสองชุดนี้บอกเรื่องเดียวกัน——AI ไม่ได้ขาดความสามารถ แต่ขาดบริบท

ณ จุดเวลาสิงหาคม 2026 วาทกรรมเรื่อง “การเร่งการเปลี่ยนผ่านสู่ AI” ทั้งหมดต้องถูกมองผ่านชุดการเปรียบเทียบนี้:

| กลุ่ม | ความคืบหน้า (H1 2026) | ตัวอย่างด้านตรงข้าม (H1 2026) |
|—|—|—|—|
| EY | ใช้งาน Microsoft 365 Copilot ครอบคลุมพนักงาน 150,000 คน ประหยัดเวลา 2.5 ล้านชั่วโมง / 250 ล้านดอลลาร์; เตรียมขยายสู่พนักงาน 40,000 คนทั่วโลก | ขณะเดียวกันก็ยอมรับว่า ตัวเลขความเร็วที่เพิ่มขึ้น 95% และต้นทุนปฏิบัติการด้านการเงินที่ลดลง 37% นั้นมีเงื่อนไขสำคัญคือ “ต้องวางมาตรฐานให้ชัดเจนก่อน” |
| Atos | ใช้งานใน 54 ประเทศ / พนักงาน 56,000 คน; รัน AI agent 19,000 ตัว พร้อมกัน โดยมี control plane กลางสำหรับจัดการเรื่อง identity/ความปลอดภัย/compliance/governance | ยึดหลัก “ต้องเปิดตัวความสามารถด้าน governance ของ Agent 365 ให้พร้อมก่อน แล้วค่อยขยายขนาด” อย่างเคร่งครัด |
| Microsoft เอง | Work Trend Index 2026: ผู้บริหาร 82% วางแผนจะใช้ AI agent ขยายกำลังคนภายใน 12-18 เดือน | ช่วงเวลาเดียวกันก็ยอมรับว่า “จังหวะของการเปลี่ยนแปลงองค์กรช้ากว่าการใช้งานในระดับบุคคล” — ซึ่งเป็นความขัดแย้งหลักในแนวคิด Frontier Firm |

ที่มา: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5; New Relic 2026 State of AI Coding Report

การเทียบเคียงสองชุดข้อมูลนี้ชี้ให้เห็นเรื่องเดียว: ถ้าไม่มีมาตรฐาน การขยายขนาดเท่ากับการคูณความเสี่ยงด้วย N ความ “เร็ว” ของ EY/Atos/Microsoft ไม่ได้แปลว่าโมเดลเร็ว แต่แปลว่า “องค์กรตอบคำถามเรื่องวิธีใช้ AI ให้เสร็จก่อน” นี่คือเบื้องหลังที่ Spec-Driven Development (SDD) กลายเป็นกระแสหลักจริง ๆ ในช่วง H1 ปี 2026 — ไม่ใช่เพราะวิศวกรชอบเอกสาร แต่เพราะถ้าไม่เขียนสเปกก็อยู่รอดไม่ได้ในสภาพแวดล้อมที่มีเอเจนต์ 19,000 ตัว

บทความนี้จะอธิบายสามเรื่อง: 1) ทำไมข้อบกพร่องของโค้ดที่ AI เขียนจึงรุนแรงกว่าโค้ดที่มนุษย์เขียนถึง 1.7 เท่าขึ้นไป; 2) ห้าแพลตฟอร์มอย่าง GitHub, AWS, OpenAI, Anthropic และ Alibaba ต่างมุ่งสู่กระบวนทัศน์เดียวกันใน H1 ปี 2026 ได้อย่างไร — ใช้เอกสารกำกับพฤติกรรมของ AI; 3) ทำไมการขับเคลื่อนด้วยสเปกจึงเป็นความสามารถขององค์กร ไม่ใช่การเลือกเครื่องมือ และสามขั้นตอนการนำไปปฏิบัติจริงใน H1 ปี 2026

รหัส AI vs รหัสคน: การกระจายข้อบกพร่อง (วิเคราะห์ PR โอเพนซอร์ส 470 รายการ) รายงาน CodeRabbit 2025.12｜ตัวเลขทั้งหมดเป็นอัตราส่วนทวีคูณของ AI/คน (เส้นฐาน 1.0)

ความยาวแท่ง = ข้อบกพร่อง AI เป็นทวีคูณของคน; เส้นฐาน 1.0× = ระดับคน

เส้นฐาน 1.0×

จำนวนปัญหาทั้งหมด

1.7×
AI 10.83 vs คน 6.45 / PR

ข้อผิดพลาดตรรกะ / ความถูกต้อง

1.75×

คุณภาพโค้ด / การบำรุงรักษา

1.64×

การค้นพบด้านความปลอดภัย (รวม)

1.57×

การจัดการรหัสผ่านไม่ถูกต้อง

1.88×

ช่องโหว่ XSS

2.74×
↑ สูงสุด

โค้ด AI ที่ไม่มีข้อกำหนดควบคุม สูงกว่าคนในทุกมิติ
การเงิน/โทรคมนาคม = การกระทบยอด合规, การจัดการรหัสผ่าน, การเข้ารหัสฟิลด์ละเอียดอ่อน AI มองไม่เห็นทั้งหมด

หนึ่ง ปัญหาอัตราความบกพร่องของ AI ไม่ใช่ปัญหาเรื่องโมเดล แต่เป็นปัญหาเรื่องบริบท

ในรายงานของ CodeRabbit มีประโยคหนึ่งที่ถูกหยิบยกมาอ้างถึงซ้ำแล้วซ้ำเล่า: “AI ขาดตรรกะทางธุรกิจในท้องถิ่น: โมเดลอนุมานรูปแบบโค้ดจากสถิติ ไม่ใช่จากความเข้าใจเชิงความหมาย หากไม่มีข้อจำกัดที่เข้มงวด โมเดลจะมองไม่เห็นกฎของระบบที่วิศวกรอาวุโสซึมซับไว้ภายใน”

ประโยคนี้อธิบายว่าทำไมแพลตฟอร์มเขียนโค้ดด้วย AI ของ CodeRabbit เอง (บริษัทที่ทำ AI code review โดยเฉพาะ) ถึงเห็นข้อมูลชุดนี้ก่อนใคร — เพราะพวกเขาดู Pull Request หลายพันรายการต่อวัน และเห็นทุกวันว่าโค้ดที่ AI เขียนออกมามีหน้าตาแบบไหน สิ่งที่ “สำคัญที่สุด” ไม่ใช่ตัวเลขรวม แต่คือการกระจายตัวของปัญหา:

  • ด้านตรรกะ/ความถูกต้อง +75%: ข้อผิดพลาดทางตรรกะธุรกิจ ข้อผิดพลาดด้าน dependency ข้อผิดพลาดด้าน control flow ข้อผิดพลาดด้านการกำหนดค่า — ปัญหากลุ่มนี้ไม่จำเป็นต้องโผล่ให้เห็นในการทดสอบเสมอไป แต่มันจะก่อให้เกิดอุบัติเหตุในสภาพแวดล้อม production
  • คุณภาพโค้ด +64%: การตั้งชื่อที่ไม่สอดคล้องกัน โครงสร้างที่ไม่ชัดเจน การละเมิดรูปแบบของโปรเจกต์ — นี่คือ “หมวดหมู่ที่มีความแตกต่างมากที่สุด” วิศวกรอาวุโสมองปราดเดียวก็รู้ทันทีว่า “นี่ไม่ใช่สไตล์การเขียนของที่นี่”
  • ความปลอดภัย +57% (XSS สูงสุด 2.74 เท่า): การจัดการรหัสผ่านที่ไม่เหมาะสม (1.88 เท่า) การอ้างอิงวัตถุที่ไม่ปลอดภัย (1.91 เท่า) การรั่วไหลของข้อมูลอ่อนไหว การ deserialization ที่ไม่ปลอดภัย (1.82 เท่า) — ในอุตสาหกรรมการเงิน นี่ไม่ใช่คำถามว่า “ใช้ได้หรือไม่” แต่คือ “ปล่อยออกไปได้หรือไม่”

ปัญหาที่แท้จริงไม่ใช่เพราะ AI ไม่เก่งพอ แต่เป็นเพราะมัน “มองไม่เห็น”

ลองกลับไปที่จุดติดจริงของ CIO ท่านนั้น กับความล้มเหลวสามอย่างของ AI ในระบบหลักของธุรกิจการเงิน:

อย่างแรก AI มองไม่เห็นตรรกะการกระทบยอดที่เขียนมา 30 ปี กฎความเสี่ยงของธนาคารถูกฝังอยู่ใน stored procedure ของระบบหลัก — เขียนเมื่อ 30 ปีก่อน ไม่มีใครจำได้ครบถ้วน โค้ดที่ AI สร้างออกมาดูเหมือนไม่มีปัญหา แต่พอรันในระบบ production จะไปชนเข้ากับเงื่อนไขการกระทบยอดที่ไม่มีใครจำได้ ส่งผลให้ธุรกรรมทั้งชุดล้มเหลว

อย่างที่สอง AI มองไม่เห็นข้อบังคับด้าน compliance รหัสผ่านต้องผ่าน key management system ฟิลด์ที่อ่อนไหวต้องเข้ารหัสก่อนจัดเก็บ log ห้ามพิมพ์ข้อมูลลูกค้า — นี่คือข้อบังคับจากหน่วยงานกำกับดูแล เขียนไว้ในระเบียบภายใน AI ไม่รู้เรื่องนี้ โค้ดที่เขียนออกมารันได้ แต่ผ่านการตรวจสอบ compliance ไม่ได้

อย่างที่สาม AI มองไม่เห็นหนี้ทางเทคนิคของคุณ ระบบหลักอายุ 30 ปี ใช้โปรโตคอลอินเทอร์เฟซเฉพาะของตัวเอง เอกสารหายไปนานแล้ว AI เขียนโค้ดตามมาตรฐาน RESTful ทั่วไป พอขึ้น production ถึงรู้ว่าอินเทอร์เฟซไม่ตรงกัน — ต้องแก้กันสองสัปดาห์

กลับไปที่ตัวเลขอีกชุดจาก New Relic: 62% ของทีม “มั่นใจจนไม่ตรวจสอบแล้วปล่อย” โค้ดที่ AI เขียน และ 78% รายงานว่ามี incident เพิ่มขึ้นหลังขึ้น production ตัวเลขสองตัวนี้รวมกันแล้วสื่อความหมายเดียว — อัตราข้อบกพร่องของโค้ด AI ไม่ใช่ปัญหาจริง “การที่ฉันไม่รู้ว่าโค้ด AI มีข้อบกพร่องอะไรบ้าง” ต่างหากคือปัญหา

สถานการณ์ทั่วไป: ธนาคารพาณิชย์แห่งหนึ่งนำ AI มาช่วยพัฒนาระบบโมดูลควบคุมความเสี่ยงของระบบหลักภายใน 3 เดือน อัตราการตีกลับจากการตรวจสอบ compliance เพิ่มขึ้นอย่างมีนัยสำคัญ ปัญหาหลักคือกฎภายในเกี่ยวกับการจัดการรหัสผ่าน การเข้ารหัสฟิลด์ข้อมูลอ่อนไหว และ compliance ของ log กฎเหล่านี้เขียนอยู่ในเอกสารภายในทั้งหมด แต่ AI มองไม่เห็น ต่อมาทีมงานเขียนกฎหลักลงในไฟล์ CLAUDE.md อัตราการตีกลับลดลงอย่างชัดเจน

สอง: ห้าแพลตฟอร์มใน H1 2026: “การขับเคลื่อนด้วยข้อกำหนด” ที่ไปสู่จุดหมายเดียวกัน

ในเดือนกรกฎาคม 2025 GitHub เปิดตัว Spec Kit ต้นปี 2026 AWS Kiro, OpenAI Codex และ Anthropic Claude Code ก็ทยอยเพิ่มฟีเจอร์นี้ครบทั้งหมด พฤษภาคม 2026 Alibaba Qoder เขียน “Spec-Driven Workflow” ลงใน positioning ของผลิตภัณฑ์ ห้าแพลตฟอร์มใน H1 2026 มาถึงกระบวนทัศน์เดียวกัน——ใช้เอกสารเพื่อควบคุมพฤติกรรมของ AI นี่ไม่ใช่สิ่งประดิษฐ์ของบริษัทใดบริษัทหนึ่ง แต่เป็นการตอบสนองร่วมกันของอุตสาหกรรมต่อ “วิกฤตคุณภาพโค้ดที่เกิดจาก AI”

เส้นทางขับเคลื่อนข้อกำหนดของห้าแพลตฟอร์ม (2025-2026 H1) GitHub Spec Kit โอเพนซอร์ส 2025.9 constitution.md เกตห้าขั้นตอน: constitution → specify → plan → tasks → implement ไม่ขึ้นกับโมเดล รองรับ 8+ เอเจนต์ Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md เวิร์กโฟลว์สามขั้นตอน: ความต้องการ → ออกแบบ → งาน spec-driven ฝังในเวิร์กโฟลว์ IDE ฮุคทริกเกอร์เอเจนต์อัตโนมัติ ฮุค compliance/audit ฝังไว้ล่วงหน้า ไม่เขียน spec เริ่มไม่ได้ OpenAI Codex 2025-2026 AGENTS.md + ระบบ Skills ชุดคำสั่งประกอบได้ คอนฟิกแชร์ระดับทีม ผู้ใช้รายสัปดาห์ 5M+ (2026.6) ไม่ใช่นักพัฒนา 20% จากโค้ดดิ้งสู่เอเจนต์ทั่วไป Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + ทักษะ (ตลาดทางการ 2026.2) + ระบบนิเวศ MCP CSAT 91% / NPS 54 $2.5B ARR（2026.2） GitHub 11.2 หมื่น stars Alibaba Qoder 2025.8 → 2026.5 Spec Workflow โหมด Quest ปฏิบัติการอัตโนมัติ + โหมด Expert ทีม + บริบท RepoWiki ผู้ใช้ทั่วโลก 5M+ (2026.5) 2026.7.21 Qoder Security CLI DingTalk เชื่อมต่อแล้ว กระบวนทัศน์ร่วม: เขียน "เราร่วมมือกับ AI อย่างไร" เป็นเอกสารอย่างชัดเจน เก็บในคลัง ให้ทุกคนและเอเจนต์ AI ทั้งหมดทำงานตามมาตรฐานเดียวกัน—นี่คือแก่นของการขับเคลื่อนด้วยมาตรฐาน

มาดูความเคลื่อนไหวล่าสุดของแต่ละแพลตฟอร์มใน H1 2026 ทีละตัว:

GitHub Spec Kit: ข้อมูลอ้างอิงมาตรฐาน พร้อมเกตควบคุม 5 ระยะ เปิดซอร์สเมื่อกันยายน 2025 และกลายเป็นข้อมูลอ้างอิงมาตรฐานของวงการภายในครึ่งแรกของปี 2026 คำสั่งหลัก 5 คำสั่ง + คำสั่งเสริม 2 คำสั่ง: /speckit.constitution (หลักการที่ไม่สามารถต่อรองได้), /speckit.specify (จะทำอะไรและทำไม), /speckit.plan (จะแก้อย่างไร), /speckit.tasks (แบ่งงานย่อย), /speckit.implement (ลงมือทำ) ตามด้วย /clarify และ /analyze จุดออกแบบที่สำคัญคือ ไม่ผูกติดกับโมเดลใดโมเดลหนึ่ง — ไฟล์ spec/plan/tasks ชุดเดียวกันไม่ผูกขาดกับเอเจนต์ที่จะนำไปปฏิบัติตัวใดตัวหนึ่ง ไม่ว่าจะเป็น Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf หรือ Qwen Code ก็เชื่อมต่อได้ทั้งหมด นี่ทำให้มันกลายเป็น “โปรโตคอล SDD ระดับองค์กร” ไม่ใช่ผลิตภัณฑ์เฉพาะของ GitHub (อ้างอิงจาก vibecoding.app รีวิว มิ.ย. 2026, คะแนน 0.816, แหล่งข้อมูลทุติยภูมิ)

AWS Kiro: ฝังมาตรฐานการเขียนสเปคไว้ใน IDE โดยตรง เปิดตัวเมื่อกรกฎาคม 2025 และพัฒนาเต็มรูปแบบเป็น Agent IDE ในช่วงครึ่งแรกของปี 2026 เวิร์กโฟลว์สามขั้นตอน: ความต้องการ → การออกแบบ → งาน จุดต่างจาก Spec Kit อยู่ที่ “ฮุค” — ไฟล์ spec ของ Kiro สามารถทริกเกอร์การทำงานของเอเจนต์ที่กำหนดไว้ล่วงหน้า ทำให้ขั้นตอนที่ต้องพึ่งพาระบบภายนอกอย่าง compliance/audit/deployment ถูกฝังไว้ในเวิร์กโฟลว์ตั้งแต่ต้น ถ้าอยากบังคับทีมให้เขียนสเปคให้เลือก Kiro — เพราะถ้าไม่เขียน spec, Kiro จะไม่เริ่มทำงาน (AWS Kiro official 2025.7; Kiro.dev docs 2026)

OpenAI Codex: AGENTS.md + Skills ที่ประกอบกันได้ ปี 2025-2026 ผลักดันให้ AGENTS.md กลายเป็นแกนกลางของระบบนิเวศ Skills คือส่วนขยายสำคัญของ H1 ปี 2026: ประกอบขั้นตอนการทำงานอย่าง “อ่านไฟล์ Excel” “สร้าง SQL” “รัน data migration” ไว้ล่วงหน้า แล้วเรียกใช้ได้เหมือนต่อเลโก้ ผู้ใช้รายสัปดาห์ของ Codex ทะลุ 5 ล้านคนในเดือนมิถุนายน 2026 โดย 20% เป็นคนที่ไม่ใช่นักพัฒนา — นี่คือสัญญาณที่หลายคนมองข้าม: การขับเคลื่อนด้วยข้อกำหนดไม่ได้จำกัดอยู่แค่ทีมวิศวกรรมอีกต่อไป แต่เป็นเรื่องของทุกคน ไม่ว่าจะเป็นฝ่ายผลิตภัณฑ์ ฝ่ายปฏิบัติการ หรือฝ่ายบริหารความเสี่ยง ต่างก็เขียน AGENTS.md กันทั้งนั้น (ประกาศของ OpenAI วันที่ 2 มิ.ย. 2026; บทวิจารณ์จาก thebcms.com ปี 2026, คะแนน 0.801)

Claude Code: CLAUDE.md + .claude/rules/ + Skills Anthropic เรียกเอกสารคำแนะนำโปรเจกต์ว่า CLAUDE.md (เข้าสู่ตลาดอย่างเป็นทางการในเดือนกุมภาพันธ์ 2026), .claude/rules/ (กฎแบบแบ่งตามไดเรกทอรี), และ Skills (เวิร์กโฟลว์ที่แชร์ได้) Claude Code เป็นเครื่องมือที่นักพัฒนาพึงพอใจสูงสุดใน H1 ปี 2026 — ตัวเลขจากงานวิจัย JetBrains 2026.1 คือ CSAT 91%, NPS 54 และสอดคล้องกับงานวิจัยอิสระอีกสองชิ้น (Pragmatic Engineer 2026.2) นี่คือคะแนนสูงสุดในวงการเครื่องมือเขียนโค้ดด้วย AI ในตอนนี้ (uvik.net 2026.5, score 0.956, รวมจากแหล่งข้อมูลหลัก) Claude Code ทะยานจากศูนย์สู่รายได้ต่อปี 2.5 พันล้านดอลลาร์ภายใน 9 เดือน (ตามรอบระดมทุน Series G ของ Anthropic, 2026.2) และมี 11.2 หมื่น stars บน GitHub (สำหรับ Skills repository) — นักพัฒนาโหวตด้วยการใช้งานจริง ซึ่งพิสูจน์คุณค่าที่แท้จริงของแนวทางที่ขับเคลื่อนด้วยกฎระเบียบ

Alibaba Qoder: แรงขับเคลื่อนจากกฎระเบียบในตลาดจีน เปิดตัวครั้งแรกในเดือนสิงหาคม 2025 และอัปเกรดเป็นเวอร์ชัน 1.0 ในวันที่ 15 พฤษภาคม 2026 โดยเปลี่ยนสถานะจาก “AI IDE” มาเป็น “Autonomous Agent Development Workbench” อย่างเป็นทางการ จุดเด่นคือ Spec-Driven Workflow ซึ่งเปิดตัวพร้อมกับโหมด Quest (การจัดการงานหลายไฟล์แบบอัตโนมัติ), โหมด Expert (การทำงานแบบขนานโดยทีมผู้เชี่ยวชาญ) และ RepoWiki (กราฟความรู้ของคลังโค้ด) ต่อมาในวันที่ 28 พฤษภาคม 2026 ได้เปิดตัว Cloud Agents (รันไทม์สำหรับเอเจนต์แบบโฮสต์เต็มรูปแบบ) ตามด้วย Qoder Security (ความสามารถด้านความปลอดภัยและ compliance) ในวันที่ 21 กรกฎาคม และเวอร์ชัน Mobile (Android/iOS/ HarmonyOS) ในเดือนเดียวกัน จนถึงเดือนพฤษภาคม 2026 มียอดผู้ใช้ทั่วโลกเกิน 5 ล้านราย และ DingTalk CLI ระบุให้เป็นหนึ่งในสภาพแวดล้อมรันเอเจนต์ที่รองรับ (Yahoo Finance 2025; Alibaba Cloud Official 2026; Baidu Baike 2026.7)

กระบวนทัศน์ร่วม：การเขียน “วิธีที่เราทำงานร่วมกับ AI” ลงเป็นเอกสารอย่างชัดเจน เก็บไว้ใน repository และให้ทุกคนและ AI agent ทุกตัวทำงานโดยอ้างอิงมาตรฐานชุดเดียวกัน รายละเอียดการ implement ของทั้งห้าแพลตฟอร์มต่างกัน (ชื่อไฟล์/จำนวนขั้นตอน/กลไก hook) แต่เป้าหมายเหมือนกันเป๊ะ

ทำไมเรื่องนี้ถึงเกิดขึ้นพร้อมกันในช่วง H1 2026? เพราะกำแพงความสามารถของ AI ข้ามไปแล้ว——Claude Code autonomous agent, Codex multi-agent แบบขนาน, Cursor การ refactor หลายไฟล์ AI ไม่ใช่ “เครื่องมือเติมโค้ด” อีกต่อไป แต่เป็น “เพื่อนร่วมงาน” เอกสาร onboarding ที่คุณให้เพื่อนร่วมงานคนใหม่ได้ คุณต้องให้ AI อ่านได้ด้วย

สาม: การขับเคลื่อนด้วยสเปกคือความสามารถขององค์กร ไม่ใช่การเลือกเครื่องมือ

นี่คือข้อที่สำคัญที่สุดสำหรับผู้บริหาร การขับเคลื่อนด้วยสเปกไม่ใช่การเลือกเครื่องมือ แต่คือการนิยาม “องค์กรของเราทำงานร่วมกับ AI อย่างไร” คุณจะเลือก GitHub Spec Kit หรือ Claude Code ไม่สำคัญ สิ่งที่สำคัญคือคุณได้เขียนสเปกลงเป็นเอกสาร ใส่ใน repository และให้ทุกคนรวมถึง AI ทำงานโดยอ้างอิงมันหรือยัง

ถ้าไม่มีสิ่งนี้ เครื่องมือดีแค่ไหนก็แค่ทำให้ทีมสร้างหนี้ทางเทคนิคได้เร็วขึ้นเท่านั้น

เมื่อมองในมุมของการปรับใช้ในวงกว้างในช่วงครึ่งแรกของปี 2026 หลักฐานยิ่งชัดเจนขึ้นไปอีก Microsoft ในรายงานทบทวนผลประกอบการ FY26 เดือนกรกฎาคม 2026 ยกกรณีของ EY และ Atos ขึ้นเป็นแม่แบบ “Frontier Firm” — ไม่ใช่เพราะโมเดลใหม่ แต่เพราะทั้งสององค์กรตอบคำถาม “จะใช้ AI อย่างไร” ได้ก่อนใคร:

EY: วางกรอบ governance ก่อน ขยายผลได้จริง EY ในช่วงปี 2024-2025 โรลเอาต์ Microsoft 365 Copilot ให้พนักงาน 150,000 คน ประหยัดเวลาได้ 2.5 ล้านชั่วโมง คิดเป็นมูลค่าประมาณ 250 ล้านดอลลาร์สหรัฐ หัวใจสำคัญคือ “สร้างกรอบการกำกับดูแล AI ก่อน”: EY ใช้ Power Platform, Copilot Studio, Azure, Foundry และ Fabric รวมเป็นชุดเครื่องมือเดียวกัน โดยเอาข้อกำหนดด้าน compliance และ audit วางอยู่บนฐานเดียวกัน นี่คือสิ่งที่ทำให้เกิดผลลัพธ์ตามมา ไม่ว่าจะเป็นความเร็วที่เพิ่มขึ้น 95% ต้นทุนฝ่ายการเงินลดลง 37% หรือการลดงาน manual workflow ได้ถึง 90% รองประธานของ EY พูดบนเวที AI Tour 2026 อย่างตรงไปตรงมา: “เราไม่ได้โรลเอาต์ AI แล้วค่อยมาเก็บกวาดเรื่อง governance ทีหลัง แต่เราสร้าง governance ให้เสร็จก่อน แล้วค่อยโรลเอาต์ AI”

Atos: ศูนย์ควบคุมเดียวสำหรับเอเจนต์ 19,000 ตัว Atos คือหนึ่งในองค์กรแรกของโลกที่ปรับใช้ Microsoft 365 E7 (Frontier Suite) และกระจาย Copilot ไปยังพนักงาน 56,000 คนใน 54 ประเทศ และในขณะเดียวกันก็รัน AI เอเจนต์พร้อมกันถึง 19,000 ตัว — ตั้งแต่ฝ่าย IT ภายใน หน่วยธุรกิจ ไปจนถึงโปรเจกต์ของลูกค้า ล้วนสร้างเอเจนต์บน Foundry + Copilot Studio กุญแจสำคัญที่ทำให้ Atos ทำสำเร็จคือ “ศูนย์ควบคุมเดียว” ที่ผูกห้าสิ่งเข้าด้วยกัน: Entra (จัดการตัวตน) + Defender (ความปลอดภัย) + Intune (จัดการอุปกรณ์) + Purview (การกำกับดูแลข้อมูล) + Agent 365 (กำกับเอเจนต์) การผูกแบบนี้ หากเทียบกับวงการการเงิน ก็คือการผูก “การปฏิบัติตามข้อกำหนดด้านความปลอดภัย + การโอนย้ายข้อมูลข้ามพรมแดน + การขึ้นทะเบียนอัลกอริทึม + การตรวจสอบบัญชี + การกำกับดูแลโมเดล” ซึ่งเป็นสถาปัตยกรรมการกำกับดูแล ไม่ใช่แค่เครื่องมือ AI ธรรมดา

เรียนรู้ AI อย่างช้าๆ

Microsoft เปิดเผย “ช่องว่างการเปลี่ยนแปลงขององค์กร”: จังหวะการเปลี่ยนแปลงขององค์กรช้ากว่าการใช้งานของแต่ละบุคคล จากการสำรวจผู้ใช้ AI จำนวน 20,000 คน ผู้นำ 82% วางแผนจะขยายกำลังคนด้วย AI agents ภายใน 12–18 เดือน แต่มีเพียง 24% ที่ปรับใช้ในระดับองค์กรแล้วเสร็จ ผู้นำ 81% คาดว่า AI agents จะถูกผสานเข้ากลยุทธ์ AI ในระดับปานกลางถึงสูง — แต่ก็มีเพียง 24% ที่ทำได้จริง ซึ่งหมายความว่าองค์กรส่วนใหญ่ยังมีช่องว่างระหว่าง “ความพร้อม” และ “การลงมือทำ” อีก 12–18 เดือน และช่องว่างนี้จะถูกเติมเต็มด้วย การขับเคลื่อนด้วยมาตรฐาน (standards-driven) เป็นหลัก

ที่มา: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, แหล่งปฐมภูมิ PDF); บทวิเคราะห์ Futurum Group 2026.1.26 (แหล่งทุติยภูมิ)

บทเรียนข้อที่ 1: การลงทุนในมาตรฐานให้ ROI สูง

โค้ดRabbit ให้ข้อมูลพื้นฐานที่ชัดเจนสำหรับการคำนวณ ROI: อัตราปัญหาจากโค้ด AI อยู่ที่ประมาณ 1.7 เท่า และการลดช่องโหว่ด้านความปลอดภัยอยู่ที่ 2.74 เท่า ซึ่งหมายความว่า:

  • งานแก้ไขซ้ำน้อยลง (ในอุตสาหกรรมการเงิน การทำรีวิวเพื่อ compliance หนึ่งรอบใช้เวลา 2-4 สัปดาห์)
  • อุบัติเหตุด้านความปลอดภัยน้อยลง (ค่าปรับจากหน่วยงานกำกับดูแลและความเสียหายต่อชื่อเสียงจากเหตุการณ์ข้อมูลรั่วไหลหนึ่งครั้ง)
  • ต้นทุนการบำรุงรักษาต่ำลง (ตัวเลขที่พบได้ทั่วไปคือการลดหนี้ทางเทคนิคลง 40%)

การเขียนไฟล์ข้อกำหนดโปรเจกต์อย่าง CLAUDE.md/AGENTS.md คือการลงทุนด้านวิศวกรรมที่ให้ผลตอบแทนสูงที่สุดในยุค AI กรณีของ EY ให้การแปลงค่าในโลกจริง—พนักงาน 150,000 คนใช้ Copilot ช่วยประหยัดเงินได้ 250 ล้านดอลลาร์สหรัฐ สิ่งที่ควรสังเกตคือ EY ประหยัดเงินได้ไม่ใช่เพราะ “เครื่องมือเก่ง” แต่เพราะ “ข้อกำหนดทำให้คุณค่าของเครื่องมือถูกเปลี่ยนเป็นผลลัพธ์จริง”

ข้อคิดที่สอง: เขียนข้อกำหนดลงในกระบวนการขององค์กร แทนที่จะพึ่งพาตัวบุคคล

ถ้าข้อกำหนดอยู่ในหัวของวิศวกรอาวุโสเพียงไม่กี่คน พอคนย้ายออกไปก็สูญหายทันที ต้องฝังลงไปใน:

  • เอกสารใน repository (AGENTS.md / CLAUDE.md / constitution.md)
  • CI gating (ตรวจสอบการปฏิบัติตามข้อกำหนดโดยอัตโนมัติ)
  • คอนฟิกที่แชร์กันทั้งทีม (ระบบ Skills ที่ทำให้ทั้งทีมใช้งานได้)

ให้มาตรฐานกลายเป็นสินทรัพย์ขององค์กร ไม่ใช่ทักษะเฉพาะบุคคล สิ่งนี้สำคัญเป็นพิเศษในภาคการเงิน—ข้อกำหนดด้าน compliance กฎความปลอดภัย และกฎธุรกิจของคุณล้วนเป็นสินทรัพย์ระดับองค์กร ไม่ใช่ “ประสบการณ์” ของวิศวกรคนใดคนหนึ่ง เอเจนต์ 19,000 ตัวของ Atos ทำงานได้ใน 54 ประเทศ เพราะการกำกับดูแลไม่ใช่เรื่องของ “ใครสักคนเข้าใจ” แต่เป็น “ระบบบังคับใช้”

บทเรียนที่สาม: Gate สำคัญกว่าความเร็ว

GitHub Spec Kit มี gate ห้าขั้นตอน (constitution → specify → plan → tasks → implement), Claude Code มีหลักการ “ไม่เขียนโค้ดก่อนที่เทสต์จะล้มเหลว”, Kiro มีข้อกำหนด “ไม่เริ่มงานถ้ายังไม่มี spec”—ทั้งหมดกำลังทำสิ่งเดียวกัน: เติม “เบรก” ระหว่าง AI กับผลลัพธ์สุดท้าย ทุกขั้นตอนมี artifact ที่ตรวจสอบได้ (spec.md, plan.md, tasks.md) และสามารถถูกปฏิเสธหรือแก้ไขได้ก่อนที่โค้ดจะถูกสร้าง

AI ยิ่งมีอิสระมากเท่าไหร่ ยิ่งต้องมี gate มากเท่านั้น คณะกรรมการอนุมัติการเปลี่ยนแปลง (Change Advisory Board) ในภาคการเงิน กระบวนการจดทะเบียนอัลกอริทึม หรือการประเมิน Cybersecurity Act (ในไทย) ล้วนเป็นการเพิ่ม gate ก่อนเข้าสู่การผลิตจริง โค้ดที่เขียนโดย AI ก็ต้องการ gate ในลักษณะเดียวกัน เพียงแต่รูปแบบต่างกัน ทีม 62% ที่ “มั่นใจจนไม่ตรวจทานก่อนปล่อย” ในรายงานปี 2026 ของ New Relic กำลังจ่ายค่าความมั่นใจนั้นด้วยอัตรา incident ที่สูงขึ้น (78%)

3 ระยะการนำมาตรฐานไปใช้ในอุตสาหกรรมการเงิน (เวอร์ชันปฏิบัติจริง H1 2026) ระยะที่ 1: สำรวจกฎระเบียบ 2-4 สัปดาห์｜ใช้เวลามากที่สุด ROI สูงสุด รายการข้อกำหนดด้าน compliance (等保/การส่งออก/การจดทะเบียน) กฎความปลอดภัย (รหัสผ่าน/การเข้ารหัส/ล็อก) กฎธุรกิจ (ควบคุมความเสี่ยง/ธุรกรรม/คิดค่าบริการ) ข้อจำกัดทางเทคนิค (อินเทอร์เฟซเก่า/ข้อจำกัดเวอร์ชัน) การกำกับดูแลซัพพลายเออร์ (สัญญา/ตรวจสอบ/ความรับผิดชอบ) รวบรวมกฎที่กระจัดกระจาย จัดระเบียบเป็นเอกสารที่มีโครงสร้าง ระยะที่สอง: นำเข้าคลัง 1-2 สัปดาห์｜ใส่คลัง, AI โหลดอัตโนมัติ CLAUDE.md / AGENTS.md constitution.md นิยาม Skills (เวิร์กโฟลว์ที่แชร์ได้) ออกแบบกระบวนการ Gate (ห้าระยะ) .claude/rules/ (กฎแบบ分层) ใส่กฎในคลัง, AI โหลดอัตโนมัติ ระยะที่สาม: ทำให้เป็นระบบ ต่อเนื่อง｜จากเครื่องมือเป็นความสามารถองค์กร CI Gate (ตรวจสอบอัตโนมัติ) การกำหนดค่าที่ทีมใช้ร่วมกัน (Skills) กลไกการอัปเดตเป็นประจำ (ทบทวนรายไตรมาส) การวัดผล (อัตราข้อบกพร่อง/อัตราผ่านการปฏิบัติตาม) การกำกับดูแลเอเจนต์ (Agent 365 ระดับหนึ่ง) มาตรฐานกลายเป็นสินทรัพย์ขององค์กร ไม่พึ่งพาบุคคลใดบุคคลหนึ่ง

ระยะแรกใช้เวลามากที่สุด แต่ ROI สูงสุด
กฎส่วนใหญ่ขององค์กรการเงินกระจัดกระจายอยู่ในเอกสาร/อีเมล/สมองคน การรวบรวมครั้งแรกใช้เวลา 3-8 สัปดาห์

สี่: สามขั้นตอนการใช้งานจริงในช่วงครึ่งปีแรกของ 2026

ตัวอย่างเส้นทางสามขั้นตอนในอุตสาหกรรมการเงิน ซึ่งอุตสาหกรรมอื่นที่มีการกำกับดูแลเข้มงวดสามารถนำไปปรับใช้ได้ แนวทางปฏิบัติของ EY และ Atos ในช่วงครึ่งปีแรกของ 2026 สอดคล้องกับสามขั้นตอนนี้พอดี

ขั้นตอนที่หนึ่ง: สำรวจและรวบรวมกฎระเบียบ (2–4 สัปดาห์)

เป็นขั้นตอนที่ใช้เวลามากที่สุด แต่ให้ ROI สูงที่สุด คือการรวบรวมกฎระเบียบที่กระจัดกระจายอยู่ตามจุดต่างๆ ขององค์กร:

  • ข้อกำหนดด้าน compliance: สำหรับธุรกิจการเงิน ขีดขั้นต่ำพื้นฐาน = Cybersecurity Act compliance (การประเมินตาม พ.ร.บ. ว่าด้วยการรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562 สำหรับ CII) + การประเมินการโอนข้อมูลข้ามพรมแดน (PDPA) + การจดทะเบียนอัลกอริทึม (AI Governance Guideline) (ขาดข้อใดข้อหนึ่งก็ยังไม่ควรนำ AI ไปใช้ในวงกว้าง) ยังมีข้อกำหนดการรายงานข้อมูลต่อหน่วยงานกำกับดูแล การปกป้องข้อมูลลูกค้า ข้อจำกัดการไหลของข้อมูลข้ามประเทศ และการกำหนดว่าข้อมูลใดบ้างที่อนุญาตให้ AI เข้าถึงได้
  • กฎด้านความปลอดภัย: การจัดการรหัสผ่าน มาตรฐานการเข้ารหัส การจัดการฟิลด์ข้อมูลที่ละเอียดอ่อน ข้อกำหนดด้าน log
  • กฎทางธุรกิจ: เกณฑ์การควบคุมความเสี่ยง เงื่อนไขการจ่ายสินไหม ข้อจำกัดการทำธุรกรรม ตรรกะการคิดค่าบริการ
  • ข้อจำกัดทางเทคนิค: อินเทอร์เฟซระบบเดิม ข้อกำหนดการตั้งชื่อฐานข้อมูล ข้อจำกัดเวอร์ชันของเฟรมเวิร์ก
  • การกำกับดูแลผู้ให้บริการ (vendor governance): วิธีกำหนดในสัญญาให้ผู้ให้บริการปฏิบัติตามมาตรฐานของเรา และวิธีตรวจสอบการใช้งาน AI ของผู้ให้บริการ

สถานการณ์ทั่วไป: บริษัทหลักทรัพย์แห่งหนึ่งพบระหว่างขั้นตอนการสำรวจว่า กฎระเบียบต่างๆ กระจัดกระจายอยู่ในเอกสาร Word จำนวนมาก, JIRA wiki, อีเมลส่วนตัว และไฟล์ Excel — หลังจากรวบรวมจัดระเบียบแล้วจึงได้รายการกฎระเบียบที่มีโครงสร้างชัดเจน วิธีการของ Atos เป็นระบบกว่า — พวกเขาแยกกฎระเบียบออกเป็น 5 ประเภท ได้แก่ “การปฏิบัติตามข้อกำหนด, ความปลอดภัย, ธุรกิจ, เทคนิค, ผู้จำหน่าย” แต่ละประเภทมีเวิร์กโฟลว์การกำกับดูแลของตัวเอง และเชื่อมต่อเข้ากับระนาบควบคุมของ Agent 365 อย่างเป็นหนึ่งเดียว

นี่ไม่ใช่งานด้านเทคนิค แต่เป็นงานด้านองค์กร — คุณต้องดึงฝ่ายปฏิบัติตามข้อกำหนด, ฝ่ายความปลอดภัย และฝ่ายธุรกิจมาร่วมโต๊ะเดียวกัน เพื่อเขียนกฎระเบียบที่ทุกฝ่ายยอมรับร่วมกัน ครั้งแรกที่ทำ องค์กรการเงินมักใช้เวลา 3-8 สัปดาห์ — แต่นี่คือสินทรัพย์องค์กรที่ถาวร

ขั้นตอนที่สอง: นำเข้าคลังเก็บ (1-2 สัปดาห์)

นำกฎระเบียบที่รวบรวมได้ในขั้นตอนแรกมาเขียนเป็นเอกสารและเก็บเข้าคลัง GitHub Spec Kit ใช้ไฟล์ constitution.md, Claude Code ใช้ CLAUDE.md, OpenAI Codex ใช้ AGENTS.md, Alibaba Qoder ใช้ Spec Workflow ชื่อไฟล์ต่างกัน แต่เป้าหมายเดียวกัน — ให้ AI โหลดกฎระเบียบเหล่านั้นทันทีที่เปิดคลังเก็บ

โครงสร้างข้อเสนอ (รูปแบบหลักของ H1 2026):

  • ภาพรวมโครงการ: ระบบนี้ทำหน้าที่อะไร ให้บริการใคร
  • หลักการที่ไม่อาจต่อรองได้: เส้นแดงด้านความปลอดภัย เส้นแดงด้านการปฏิบัติตามกฎระเบียบ เส้นแดงด้านธุรกิจ
  • เทคโนโลยีและข้อจำกัด: ใช้เฟรมเวิร์กอะไร ฐานข้อมูลอะไร มาตรฐานอินเทอร์เฟซอะไร
  • มาตรฐานโค้ด: ข้อตกลงการตั้งชื่อ โครงสร้างไดเรกทอรี ข้อกำหนดขั้นต่ำของความครอบคลุมการทดสอบ (ไม่บังคับจังหวะ TDD — ระบุอัตราความครอบคลุมการทดสอบ พาธที่ต้องทดสอบ และพาธต้องห้ามให้ชัดเจนก็พอ TDD เป็นจังหวะที่องค์กรเลือกใช้ได้ ไม่ใช่ข้อบังคับเชิงมาตรฐาน)
  • กฎธุรกิจ: ตรรกะการควบคุมความเสี่ยง กฎธุรกรรมการซื้อขาย กฎการคิดค่าบริการ
  • ข้อกำหนดการปฏิบัติตามกฎระเบียบ: การประเมิน Cybersecurity Act (ตาม พ.ร.บ. ความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562), การส่งข้อมูลข้ามพรมแดน (ตาม PDPA), การรายงานต่อหน่วยงานกำกับดูแล, อัลกอริทึมที่สร้างโดย AI ต้องลงทะเบียนหรือไม่ (ตาม AI Governance Guideline ของ ETDA)
  • แนวปฏิบัติการใช้ AI: สถานการณ์ใดใช้ AI ได้ สถานการณ์ใดต้องให้มนุษย์ตรวจสอบ หลักเกณฑ์การส่งข้อมูลข้ามพรมแดน
  • การกำกับดูแลผู้ให้บริการ: เงื่อนไขสัญญา กลไกการตรวจสอบ การแบ่งความรับผิดชอบ

ภาคผนวก: โครงร่าง CLAUDE.md ฉบับการเงิน (ประมาณ 200 บรรทัด พร้อม fork ไปปรับใช้ได้เลย)

ต่อไปนี้คือโครงร่าง CLAUDE.md สำหรับการปรับปรุงระบบ core banking ของธนาคารพาณิชย์ โดยจัดลำดับตาม “หลักการที่ไม่อาจต่อรองได้ → ข้อกำหนดการปฏิบัติตามกฎระเบียบ → แนวปฏิบัติการใช้ AI → กฎธุรกิจ → ข้อจำกัดด้านวิศวกรรม” คุณไม่จำเป็นต้องเริ่มจากศูนย์ — แค่เติมกฎเฉพาะของคุณลงในช่องว่างก็พอ

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
# CLAUDE.md — <ชื่อระบบ> มาตรฐานการทำงานร่วมกับ AI

> ขอบเขตการใช้งาน: <ชื่อระบบ> v<เวอร์ชัน> ตัวแทน AI ทุกตัว (Claude Code / Cursor / Copilot / Codex)
> ที่ทำงานในคลังนี้ต้องปฏิบัติตามมาตรฐานนี้อย่างเคร่งครัด เอกสารนี้ดูแลโดย <คณะกรรมการกำกับดูแล> มีการทบทวนทุกไตรมาส
> อัปเดตล่าสุด: YYYY-MM-DD

## 1. ภาพรวมโครงการ
- **ตำแหน่งทางธุรกิจ**: ชื่อระบบหลัก / กลุ่มลูกค้าที่ให้บริการ / ประเภทธุรกรรมหลัก
- **ห่วงโซ่ที่สำคัญ**: ธุรกรรม → การควบคุมความเสี่ยง → การชำระบัญชี → การกระทบยอด → การรายงาน
- **ช่วงเวลาที่ห้ามปรับเปลี่ยน**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (ห้ามดำเนินการเปลี่ยนแปลงใด ๆ)
- **การพึ่งพาหลัก**: ต้นทาง <ระบบ> ปลายทาง <ระบบ> แพลตฟอร์มการรายงานตามกฎระเบียบ

## 2. หลักการที่ไม่สามารถต่อรองได้ (เส้นแดง ละเมิดแล้วปฏิเสธการ merge)

### 2.1 เส้นแดงด้านความปลอดภัย
- รหัสผ่าน กุญแจเข้ารหัส และ Token ต้องใช้ KMS (บริการจัดการกุญแจเข้ารหัส) เท่านั้น **ห้าม hardcode** **ห้ามพิมพ์ลง log**
- ฟิลด์ข้อมูลอ่อนไหวของลูกค้า (เลขบัตรประชาชน / เลขบัตร / CVV / เบอร์โทรศัพท์) **ต้องเข้ารหัสจัดเก็บ** ห้ามเก็บเป็น plaintext ลงฐานข้อมูล
- ห้ามปรากฏใน log: เลขบัตรประชาชนแบบเต็ม เลขบัตรแบบเต็ม รหัสผ่านแบบ plaintext ชุดค่าผสมชื่อลูกค้า+เบอร์โทรศัพท์
- การเรียกใช้ API ภายนอกต้องผ่าน API Gateway ห้ามเชื่อมต่อโดยตรง

### 2.2 เส้นแดงด้านการปฏิบัติตามข้อกำหนด
- โค้ดที่ AI สร้างขึ้น หากเกี่ยวข้องกับการเข้าถึงข้อมูลลูกค้า ต้องระบุ "การเข้าถึงข้อมูล: <ฟิลด์>" ในคำอธิบาย PR
- ห้ามถ่ายโอนข้อมูลข้ามพรมแดน **การส่งข้อมูลออกนอกประเทศทุกครั้งต้องผ่านกระบวนการประเมินการถ่ายโอนข้อมูลข้ามพรมแดน** (ติดต่อฝ่ายกำกับดูแล)
- การตัดสินใจด้วยอัลกอริทึม (สินเชื่อ / การตั้งราคาประกัน / การป้องกันการฉ้อโกง) ต้องคงช่องทางให้มนุษย์ตรวจสอบซ้ำ
- การเปลี่ยนแปลงโมเดลต้องดำเนินการลงทะเบียนอัลกอริทึม ต้องอ้างอิงเลขทะเบียนในคำอธิบาย PR

### 2.3 เส้นแดงด้านธุรกิจ
- การเปลี่ยนเกณฑ์การควบคุมความเสี่ยงต้องมีหัวหน้าฝ่ายควบคุมความเสี่ยง + หัวหน้าฝ่ายธุรกิจลงนามร่วมกัน
- การดำเนินการที่เกี่ยวข้องกับเงินของลูกค้าต้องออกแบบให้ idempotent + มีการ rollback เมื่อล้มเหลว
- การเปลี่ยนวงเงินธุรกรรม อัตราค่าธรรมเนียม และพารามิเตอร์ผลิตภัณฑ์ ต้องดำเนินการผ่านแพลตฟอร์มการจัดการพารามิเตอร์ ห้าม hardcode ในโค้ด

## 3. สแต็กเทคโนโลยีและข้อจำกัด
- **ภาษา**: Java 17 (ระบบหลัก) / Kotlin (โมดูลใหม่) / SQL (ฐานข้อมูล)
- **เฟรมเวิร์ก**: Spring Boot 3.x + Spring Cloud Alibaba
- **ฐานข้อมูล**: OceanBase 4.x (โหมดที่เข้ากันได้กับ MySQL) **ห้ามใช้ foreign key**
- **มาตรฐานอินเทอร์เฟซ**: ภายในใช้ gRPC ทั้งหมด อินเทอร์เฟซภายนอกใช้ OpenAPI 3.0 RESTful จำกัดเฉพาะอินเทอร์เฟซสำหรับจัดการเท่านั้น
- **ข้อตกลงการตั้งชื่อ**: คลาส Java ใช้ PascalCase เมธอดใช้ camelCase ค่าคงที่ใช้ UPPER_SNAKE ชื่อตาราง `t_<โดเมนธุรกิจ>_<เอนทิตี>` ดัชนี `idx_<ตาราง>_<ฟิลด์>_<ลำดับ>`
- **โครงสร้างแพ็กเกจ**: `com.<บริษัท>.<โดเมนธุรกิจ>.<ซับโดเมน>.<เลเยอร์>` (เช่น `com.bank.pay.tx.core.service`)

## 4. มาตรฐานโค้ด
- **การครอบคลุมการทดสอบขั้นต่ำ**: ห่วงโซ่หลัก ≥ 80% ยูทิลิตี้ ≥ 60% โค้ดใหม่ที่ส่งผ่าน PR ต้องมี test ด้วย
- **เส้นทางที่ต้องทดสอบ**: controller ทุกตัวต้องมี integration test (รวม failure path) enum ทุก branch ต้องมี unit test
- **เส้นทางต้องห้าม**: ห้ามแก้ไขไดเรกทอรี `<โมดูลภาระสืบทอด>` ต้องสร้าง adaptation layer ขึ้นก่อน
- **การจัดการ dependency**: การเพิ่ม dependency ของบุคคลที่สามต้องผ่านการสแกน SCA + การอนุมัติด้านความปลอดภัย

## 5. กฎธุรกิจ (ตามโดเมน)
### 5.1 ธุรกรรม
- วงเงินต่อรายการ: <จำนวนเงิน> วงเงินต่อวัน: <จำนวนเงิน> หากเกินให้ใช้การอนุมัติโดยมนุษย์
- ช่วงเวลาทำธุรกรรม: <HH:MM> ~ <HH:MM>
- การตรวจสอบธุรกรรมซ้ำ: ภายใน <ช่วงเวลา> หาก <ฟิลด์> เดียวกันถือว่าซ้ำ

### 5.2 การควบคุมความเสี่ยง
- ลำดับความสำคัญของการจับคู่บัญชีดำ: บัญชีดำภายใน → บัญชีดำที่หน่วยกำกับดูแลส่งลงมา → การอายัดทางศาล
- เกณฑ์เอาต์พุตของโมเดลป้องกันการฉ้อโกง: <คะแนน> หากเกินกว่านี้ต้องมีมนุษย์ตรวจสอบรอบที่สอง

### 5.3 การเรียกเก็บเงิน
- การเปลี่ยนอัตราค่าธรรมเนียมต้องมีเวอร์ชัน + เวลาที่มีผลบังคับใช้
- คำสั่งซื้อในอดีตคำนวณตามอัตราค่าธรรมเนียม ณ เวลาที่มีผลบังคับใช้ ไม่มีการย้อนหลัง

## 6. ข้อกำหนดการปฏิบัติตาม
- การป้องกันข้อมูลหลายระดับ (MLPS) ระดับ 3: <หน่วยงานที่ทดสอบ>, <วันที่ทดสอบครั้งถัดไป>
- การประเมินการถ่ายโอนข้อมูลข้ามพรมแดน: ขอบเขตการใช้งาน (เฉพาะโมดูลธุรกิจข้ามพรมแดนเท่านั้น)
- การลงทะเบียนอัลกอริทึม: ขอบเขตการใช้งาน (สินเชื่อ / การตั้งราคาประกัน และอัลกอริทึมสำคัญอื่น ๆ) เลขทะเบียน `<เลขทะเบียน>`
- การรายงานตามกฎระเบียบ: ตารางการแมปฟิลด์ของ <หน่วยกำกับดูแล> อยู่ที่ `<เส้นทาง>`

## 7. มาตรฐานการใช้ AI
- **สถานการณ์ที่อนุญาตให้ใช้ AI**: CRUD ทั่วไป การสร้าง unit test ร่างเอกสาร คำแนะนำเพิ่มประสิทธิภาพ SQL
- **สถานการณ์ที่ต้องให้มนุษย์ตรวจสอบ**: ตรรกะการควบคุมความเสี่ยง กฎการเรียกเก็บเงิน การควบคุมสิทธิ์ การเข้ารหัส/ถอดรหัส ข้อมูลข้ามพรมแดน
- **สถานการณ์ที่ห้ามให้ AI ดำเนินการเพียงลำพัง**: เอกสารอนุมัติ Change Advisory Board (CAB) การดำเนินการเปลี่ยนแปลงในระบบจริง การตอบสนองเหตุฉุกเฉิน
- **กฎการส่งข้อมูลออกนอกประเทศ**: ข้อมูลฝึกฝน / คำสั่ง prompt / log เอาต์พุต ห้ามส่งออกนอกประเทศทั้งหมด ให้ใช้เวอร์ชัน deploy แบบ local (<ผู้จำหน่าย>) เป็นลำดับแรก
- **ข้อกำหนดการตรวจสอบ**: โค้ดที่ AI สร้างขึ้นทั้งหมดต้องระบุ "AI ช่วยเขียน: <ชื่อเครื่องมือ>" ในคำอธิบาย PR

## 8. การกำกับดูแลผู้จัดหา
- **การรับเข้าผู้จัดหา**: ต้องส่งรายงาน SOC 2 / ISO 27001 โมเดล AI ต้องมี model card
- **ข้อกำหนดในสัญญา**: กรรมสิทธิ์ข้อมูล ความสามารถในการอธิบายโมเดล ข้อกำหนดการยกเลิก สิทธิ์ในการตรวจสอบ
- **กลไกการตรวจสอบ**: ตรวจสอบการใช้ AI ของผู้จัดหาทุกไตรมาส ผู้จัดหาที่มีความเสี่ยงสูงตรวจสอบทุกเดือน

## 9. การกำกับดูแลและการอัปเดต
- **เจ้าของ**: <คณะกรรมการกำกับดูแล> (การปฏิบัติตามข้อกำหนด + ความปลอดภัย + สถาปัตยกรรม + ธุรกิจ)
- **ความถี่ในการอัปเดต**: ทบทวนทุกไตรมาส การเปลี่ยนแปลงฉุกเฉินใช้ช่องทางด่วน (ลงนามร่วมกัน + ประกาศ 24 ชั่วโมง)
- **บันทึกการเปลี่ยนแปลง**: ดูที่ `CLAUDE_CHANGELOG.md`
- **การจัดการการละเมิด**: ละเมิดครั้งที่ 1 = ตักเตือน + บังคับอบรม ละเมิดครั้งที่ 2 = ระงับการใช้เครื่องมือ AI ละเมิดครั้งที่ 3 = ยกเลิกสิทธิ์

โครงร่างนี้ไม่ใช่ “คำตอบมาตรฐาน” แต่เป็น “แม่แบบสำหรับเติมช่องว่าง” สิ่งที่สำคัญกว่าการเขียนให้ยาวแค่ไหนคือการเติมแต่ละช่องด้วยอะไร—ช่องว่างที่เว้นไว้คือส่วนที่เผยให้เห็นว่า “บริษัทของคุณยังไม่ได้คิดให้ชัด” ในเรื่องนั้น

ตัวอย่างสถานการณ์ทั่วไป: ธนาคารพาณิชย์แห่งหนึ่งกำหนดกฎใน CLAUDE.md ไว้โดยเฉพาะสำหรับการจัดการรหัสผ่าน—โค้ดที่ AI สร้างขึ้นซึ่งเกี่ยวข้องกับรหัสผ่านต้องเรียกใช้ Internal Key Management API เท่านั้น ห้าม Hardcode โดยเด็ดขาด กฎลักษณะนี้คิดเป็นสัดส่วนสูงมากในสาเหตุที่ถูกตีกลับจากการตรวจสอบ Compliance

ฟิลด์ใหม่ที่สำคัญใน H1 2026 คือ Skills/คำนิยาม Workflow—ไม่ใช่แค่เอกสาร แต่เป็น Toolchain ที่ AI สามารถเรียกใช้ได้จริง ระบบ Skills ของ Claude Code (เข้าสู่ Official Marketplace ของ Anthropic เมื่อกุมภาพันธ์ 2026 มี 1.12 แสน stars บน GitHub) ทำให้ขั้นตอนอย่าง “อ่านไฟล์ Excel” “สร้าง SQL” “รัน Data Migration” กลายเป็น Workflow ที่แชร์ร่วมกันได้ นี่คือวิวัฒนาการสำคัญของแนวทางที่ขับเคลื่อนด้วยมาตรฐาน (Norm-driven) ใน H1 2026: มาตรฐานไม่ใช่แค่ข้อจำกัด แต่เป็น Workflow ที่ปฏิบัติการได้

ระยะที่สาม: การทำให้เป็นสถาบัน (ต่อเนื่อง)

การเขียนมาตรฐานให้เสร็จไม่ใช่จุดจบ แต่เป็นจุดเริ่มต้น คุณต้องทำให้มันกลายเป็นส่วนหนึ่งของกระบวนการขององค์กร:

  • CI Gate Integration: ตรวจสอบอัตโนมัติว่าโค้ดปฏิบัติตามมาตรฐานหรือไม่ (เช่น ตรวจหาการ hardcode รหัสผ่าน, ฟิลด์ข้อมูลอ่อนไหวที่ไม่เข้ารหัส)
  • Shared Team Configuration: ใช้ระบบ Skills เพื่อให้ทั้งทีมใช้มาตรฐานชุดเดียวกัน
  • Regular Update Mechanism: เมื่อกติกาเปลี่ยน มาตรฐานก็ต้องเปลี่ยนตาม (ทบทวนรายไตรมาส)
  • Metrics and Feedback: ติดตามอัตราข้อบกพร่องของโค้ดที่เขียนโดย AI, อัตราการผ่านการตรวจสอบ compliance, อัตราการแก้ไขซ้ำ
  • Agent Governance: ขยายการกำกับดูแลจากคนไปสู่ AI agent — สิ่งที่ Atos ทำบน Agent 365 คือการทำให้เรื่องนี้เป็น “ระดับระบบ” แทนที่จะเป็น “ระดับบุคคล”

EY และ Atos ในช่วง H1 ปี 2026 ต่างทำให้ระยะที่สามกลายเป็น “ขีดความสามารถขององค์กร” การประหยัดเวลา 2.5 ล้านชั่วโมงของ EY เกิดจากการทำระยะที่หนึ่งและระยะที่สามได้ถูกต้อง — ระยะที่สองเป็นเพียงการแปลกติกาให้เป็นเอกสารที่ AI อ่านได้

ห้า: รูปแบบสำหรับอุตสาหกรรมที่มีการกำกับดูแลเข้มงวด: แนวทางวิศวกรรมสามแบบสำหรับการฝัง compliance

อุตสาหกรรมที่มีการกำกับดูแลเข้มงวด เช่น การเงิน โทรคมนาคม และการแพทย์ มีอุปสรรคเพิ่มอีกขั้นในการนำมาตรฐานไปปฏิบัติเมื่อเทียบกับอุตสาหกรรมทั่วไป — compliance ไม่ใช่สิ่งที่มาแนบกับกระบวนการ แต่ต้องถูก built-in อยู่ในโค้ด แนวทางสามแบบด้านล่างนี้เป็นวิธีการฝัง compliance ที่ได้รับการพิสูจน์แล้วในช่วง H1 ปี 2026 ซึ่ง CIO และผู้บริหารฝ่ายดิจิทัลสามารถใช้อ้างอิงได้โดยตรงในการออกแบบองค์กร

5.1 การฝังผู้แทนฝ่ายกำกับดูแลในทีมสตรีม: ทำให้การกำกับดูแล “อยู่ร่วมในกระบวนการ” ไม่ใช่ “รออนุมัติทีหลัง”

แนวทางเดิม: ทีมพัฒนาธุรกิจเขียนโค้ด ฝ่ายกำกับดูแลตรวจสอบทีหลัง—พอตรวจพบปัญหา โค้ดก็ขึ้น production ไปครึ่งเดือนแล้ว ต้นทุนในการแก้ไขใหม่คือ 2-4 สัปดาห์ ปัญหาที่แท้จริงคือการกำกับดูแลอยู่ท้ายสุดของกระบวนการ

แนวทางใหม่: ฝังผู้แทนฝ่ายกำกับดูแลไว้ในทุกทีมสตรีม (stream-aligned team) โดยใช้โครงสร้างรายงานแบบคู่—“สายตรงขึ้นกับฝ่ายกำกับดูแล สายรายงานประจำขึ้นกับทีมธุรกิจ” รายละเอียดการออกแบบ:

  • อัตรากำลังคน: ผู้แทนฝ่ายกำกับดูแล 1 คนต่อทุก 6-8 ทีมสตรีม สังกัดฝ่ายกำกับดูแล แต่ที่นั่งทำงานอยู่กับทีมธุรกิจ—ไม่ใช่การ “ยืมตัว” แบบไปช่วยงานชั่วคราว
  • KPI แบบคู่สาย: น้ำหนัก 50% ของ KPI ผู้แทนฝ่ายกำกับดูแลผูกกับ “อัตราข้อบกพร่องด้านการกำกับดูแล” และ “อัตราผ่านการตรวจสอบในครั้งเดียว” ของทีมธุรกิจ ไม่ใช่ดูแค่ “ความครอบคลุมของการตรวจสอบ” ของฝ่ายกำกับดูแล
  • เข้าแทรกตั้งแต่ต้น: ผู้แทนฝ่ายกำกับดูแลเข้าร่วม daily stand-up (สัปดาห์ละ 1 ครั้งก็เพียงพอ), ร่วมตรวจ PR และโค้ดที่ AI สร้างขึ้นต้องผ่านผู้แทนฝ่ายกำกับดูแลก่อน merge—ไม่ใช่ถูกตรวจพบทีหลังแล้วค่อยมาแก้
  • เครื่องมือสนับสนุน: ผู้แทนฝ่ายกำกับดูแลใช้ Skills ของ checklist การกำกับดูแลแทนการไล่เช็ครายการด้วยตนเองทีละข้อ

5.2 ทำให้ Compliance เป็น Enabling Team: เปลี่ยนข้อจำกัดให้เป็น Affordance

ตัวอย่างจริง: ธนาคารพาณิชย์ระดับประเทศแห่งหนึ่งนำร่องใน H1 2026 โดยให้ทีม 3 สควอด (stream-aligned teams) ฝังตัวแทน compliance เข้าไปในทีม ทำให้อัตราการตีกลับโค้ด AI ที่ไม่ผ่านข้อกำหนดด้าน compliance ลดลงจาก 35% เหลือ 8% — หัวใจสำคัญไม่ใช่การที่ compliance “เข้มงวดขึ้น” แต่คือการที่ compliance “มองเห็นปัญหาได้เร็วขึ้น” กุญแจสำคัญของแนวทางนี้คือ KPI แบบ dotted-line ของ compliance representative ต้องสอดคล้องกับเป้าหมายธุรกิจ — ถ้า KPI ของ compliance representative ยังวัดผลจากงานที่ compliance department มอบหมายให้ทำเพียงอย่างเดียว การฝังตัวในทีมก็จะล้มเหลว

วิธีเดิม: ทีม compliance ทำหน้าที่เป็น “ยามเฝ้าประตู” ส่วนทีมธุรกิจมอง compliance เป็น “ตัวสร้างปัญหา” ทั้งสองฝ่ายเล่นเกมผลรวมเป็นศูนย์ (zero-sum game)

วิธีใหม่: ปรับโครงสร้างทีม compliance ตามรูปแบบ enabling team ของ Team Topologies — ไม่ลงไปเขียนโค้ดเอง ไม่ลงไปตรวจ PR โดยตรง แต่ส่งมอบสามสิ่งให้ทีมธุรกิจสามารถ “ปฏิบัติตามข้อกำหนดได้ด้วยตัวเอง”:

  1. การตรวจสอบ compliance ใน CI pipeline: เปลี่ยนจุดที่ต้องตรวจสอบ compliance ความถี่สูง เช่น การ hardcode รหัสผ่าน การเก็บข้อมูล sensitive เป็น plaintext การส่งข้อมูลข้ามประเทศ และจุดตัดสินใจด้วยอัลกอริทึม ให้เป็น gate บังคับใน GitHub Actions / GitLab CI เมื่อทีมธุรกิจสร้าง PR จะ trigger การตรวจสอบอัตโนมัติ ถ้าไม่ผ่าน compliance จะ fail ทันที — ไม่ต้องให้เจ้าหน้าที่ compliance มานั่งตรวจด้วยตนเองทีละรอบ

  2. ทำให้ข้อกำหนดด้าน regulation เป็น affordance (ข้อจำกัดที่ตอบสนองต่อสภาพแวดล้อม): เช่น ตอนพัฒนาฟีเจอร์ที่เกี่ยวข้องกับข้อมูลลูกค้า IDE plugin จะเด้งคำแนะนำขึ้นมาว่า “ฟิลด์นี้แนะนำให้เรียกใช้ KMS” หรือตอนเขียน log ระบบจะตรวจจับอัตโนมัติว่ามีข้อมูล sensitive ปนอยู่หรือไม่ แล้วแจ้งเตือนทันที ทำให้ข้อกำหนด compliance กลายเป็น “สิ่งที่เกิดขึ้นโดยธรรมชาติระหว่างการพัฒนา” ไม่ใช่ “มารู้ทีหลังตอนจะ deploy ว่าทำอะไรผิดไป”

  3. Shared Skills Library + การฝึกอบรม compliance: ทีม compliance ดูแลชุด “Compliance Skills” ไว้ เมื่อพนักงานใหม่เข้าทำงาน หรือมีการย้ายทีมข้ามสายงาน ก็เรียกใช้ชุดนี้ได้ทันที — เปลี่ยนความรู้ด้าน compliance จาก “เอกสาร” เป็น “เครื่องมือที่ใช้งานได้จริง”

ตัวอย่างสถานการณ์จริง: ธนาคาร regional แห่งหนึ่งเปิดตัว CI compliance gate + IDE compliance alert ในช่วง H1 ปี 2026 ทำให้เวลาตรวจสอบ AI code compliance ลดลงจากเฉลี่ย 45 นาที/ครั้ง เหลือ 8 นาที/ครั้ง หัวใจสำคัญไม่ใช่ “การตรวจสอบ compliance เร็วขึ้น” แต่คือ “AI ไม่ทำผิดตั้งแต่ตอนสร้างโค้ด”

5.3 Dual-Track Compliance: จัดชั้นให้สอดคล้องกับจังหวะของธุรกิจ

รายละเอียดสุดท้าย: เรื่อง compliance ไม่ควรใช้แนวทาง “เหมารวม one-size-fits-all” ควรแบ่งกฎตามระดับความเสี่ยงเป็นสองชั้น:

  • กฎความเสี่ยงสูง (เกี่ยวข้องกับเงินลูกค้า / การตัดสินใจด้วยอัลกอริทึม / ข้อมูลข้ามพรมแดน / เส้นแดงด้าน Cybersecurity Act) ใช้การควบคุมแบบเข้มงวด: ต้องมีมนุษย์ตรวจสอบ + AI ยืนยันซ้ำ + ลงทะเบียนกับ Change Advisory Board (CAB) (Change Advisory Board)
  • กฎความเสี่ยงต่ำ (โค้ดเทมเพลต CRUD / โค้ดประเภทเครื่องมือ / การสร้างเอกสาร) ใช้การควบคุมแบบ self-service: ให้ CI ตรวจสอบอัตโนมัติก็พอ ไม่ต้องให้มนุษย์ตรวจสอบ

Control plane ของ Agent 365 จาก Atos โดยพื้นฐานก็คือการแบ่งชั้นแบบนี้—เอเจนต์ในระดับต่างกันผูกกับข้อกำหนดด้านธรรมาภิบาลที่ต่างกัน การแบ่งชั้นกฎ compliance ตามระดับความเสี่ยงจะทำให้ทีมธุรกิจรู้สึกว่า “compliance ไม่ได้มาคอยขัดขวางเราทุกจุด”

ข้อสรุปรวมของสามเรื่องนี้: การฝัง compliance ไม่ใช่การเพิ่มขั้นตอนอีกหนึ่งขั้น แต่คือการออกแบบโครงสร้างและแรงจูงใจของทีมใหม่ ถ้าฝ่าย compliance ของคุณยังอยู่ในโหมด “ตรวจสอบทีหลัง” การนำการขับเคลื่อนด้วยมาตรฐานไปใช้จริงจะไปติดอยู่ที่ด่านที่ยากที่สุดนั่นคือ “การทำให้เป็นสถาบัน”—ฝ่าย compliance ต้องเปลี่ยนตัวเองก่อน ทีมธุรกิจถึงจะขับเคลื่อนด้วยมาตรฐานได้อย่างลื่นไหล

หก: คำถามที่คุณอาจอยากถาม

“เรามี coding standard อยู่แล้ว มันต่างกันยังไง?”

Coding standard ดูแลเรื่อง “เขียนโค้ดอย่างไร” ส่วนการขับเคลื่อนด้วยมาตรฐาน (spec-driven) ดูแลเรื่อง “ทำงานร่วมกับ AI อย่างไร” Coding standard ไม่ครอบคลุม: กฎธุรกิจ ข้อกำหนด compliance และนโยบายการใช้ AI การขับเคลื่อนด้วยมาตรฐานคือการทำให้ “กระบวนการทั้งหมดของการทำงานร่วมกันระหว่างคนกับ AI” ชัดเจนเป็นรูปธรรม ไม่ใช่แค่คู่มือสไตล์การเขียนโค้ด

“การเขียนสเปคจะทำให้การพัฒนาซอฟต์แวร์ช้าลงหรือไม่?”

ในระยะสั้นอาจช้าลง แต่ในระยะยาวไม่ช้าแน่นอน ข้อมูลจาก CodeRabbit ให้คำตอบที่ชัดเจน: โค้ดที่เขียนโดย AI โดยไม่มีข้อกำหนดกำกับมีความเสี่ยงต่อข้อบกพร่องสูงกว่าประมาณ 1.7 เท่า และมีความเสี่ยงด้านช่องโหว่ความปลอดภัยสูงถึง 2.74 เท่า ในอุตสาหกรรมการเงิน การแก้ไขงานเพื่อให้ผ่านการตรวจสอบ compliance ในแต่ละครั้งใช้เวลา 2-4 สัปดาห์ — ถ้าประหยัดการแก้ไขซ้ำได้สักครั้ง ก็เท่ากับว่าคุณมีเวลาเขียนสเปคทั้งเดือน รายงานของ EY ที่ประหยัดต้นทุนได้ 250 ล้านดอลลาร์ คือหลักฐานจริงที่แสดงให้เห็นว่าการทำเรื่องนี้ให้เป็นความสามารถระดับองค์กรนั้นให้ผลลัพธ์ที่คุ้มค่า

“ทีมเราไม่มีใครเขียนสเปคเป็น จะทำอย่างไร?”

ไม่จำเป็นต้องเริ่มจากศูนย์ GitHub Spec Kit, Claude Code Superpowers และ AWS Kiro ต่างมีเทมเพลตให้ใช้อยู่แล้ว สิ่งที่คุณต้องทำคือเติมกฎเฉพาะขององค์กรของคุณลงไป — ซึ่งส่วนใหญ่เป็นกฎด้าน compliance และความปลอดภัย ที่จริงแล้วแผนก compliance และแผนกความปลอดภัยของคุณเขียนไว้อยู่แล้ว เพียงแต่มันไม่ได้ถูกวางไว้ในที่ที่ AI เข้าถึงได้เท่านั้นเอง

“เครื่องมือ AI มีเยอะแยะ จะเลือกตัวไหนดี?”

ไม่สำคัญ เลือกเครื่องมือที่คุณใช้อยู่แล้วก็พอ หลักการคือ “ยึดมาตรฐาน ไม่ผูกขาดเครื่องมือ” — ไฟล์ CLAUDE.md ใช้ได้ทั้งใน Claude Code, Cursor และ Codex ส่วน AGENTS.md รันได้ในระบบนิเวศของ OpenAI ขณะที่ constitution.md เป็นรูปแบบที่ไม่ผูกกับโมเดลใดโดยเฉพาะ สิ่งสำคัญคือการเขียนมาตรฐานให้ดี ไม่ใช่การเปลี่ยนเครื่องมือ EY ลงระบบนิเวศ Microsoft, Atos ก็ลงระบบนิเวศ Microsoft เช่นกัน ความต่างของตัวเครื่องมือเป็นเพียงเปลือกนอก แต่ความเหมือนกันของโครงสร้างการกำกับดูแลต่างหากคือแก่นแท้

“EU AI Act จะมีผลบังคับใช้เต็มรูปแบบในเดือนสิงหาคม 2026 — เรื่องนี้กระทบเราไหม?”

มีครับ EU AI Act เข้าสู่ช่วงบังคับใช้เต็มรูปแบบตั้งแต่วันที่ 2 สิงหาคม 2026 โดยมีข้อกำหนดบังคับสำหรับระบบ AI ความเสี่ยงสูง (รวมถึงการให้สินเชื่อ การกำหนดเบี้ยประกัน การคัดกรองผู้สมัครงาน และโครงสร้างพื้นฐานที่สำคัญ) ได้แก่ การบริหารความเสี่ยง (Art. 9) การกำกับดูแลข้อมูล (Art. 10) ความโปร่งใสด้านเอกสาร (Art. 11–13) การควบคุมโดยมนุษย์ (Art. 14) และความแม่นยำ/ความทนทานของระบบ (Art. 15) ค่าปรับสูงสุดอยู่ที่ 35 ล้านยูโรหรือ 7% ของรายได้ทั่วโลก สำหรับบริษัทจีนที่ขยายตลาดต่างประเทศ ตลาดยุโรปคือโจทย์ที่เลี่ยงไม่ได้ ส่วนบริษัทในประเทศ กรอบของ EU AI Act ก็เป็นมาตรฐานที่ถูกอ้างอิงมากที่สุดในระดับโลก—แม้คุณอาจไม่ต้องปฏิบัติตามโดยตรง แต่ก็ยากที่จะหลีกเลี่ยงผลกระทบที่ส่งผ่านมาทางซัพพลายเออร์ พันธมิตรทางธุรกิจ และธุรกรรมข้ามพรมแดน (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6)

“เทียบกับบ้านเรา: EU กำกับ AI แต่บ้านเรากำกับอะไร?”

การกำกับดูแล generative AI ในจีนใช้แนวทางสามประสานคือ “การจดทะเบียนอัลกอริทึม + การตรวจสอบคลังข้อมูล + การประเมินความปลอดภัย” โดยมีกฎหมายหลักคือ《ข้อบังคับชั่วคราวว่าด้วยการบริหารจัดการบริการปัญญาประดิษฐ์เชิงสร้างสรรค์》(Interim Measures for the Management of Generative AI Services) ซึ่งมีผลบังคับใช้ตั้งแต่เดือนสิงหาคม 2023 ความแตกต่างที่ใหญ่ที่สุดระหว่างสองกรอบนี้ไม่ได้อยู่ที่รายละเอียดของข้อกำหนด แต่อยู่ที่ปรัชญาทางกฎหมายที่แตกต่างกัน

มิติEU AI Actระเบียบการบริหารจัดการบริการ Generative AI ของจีน
สถานะทางกฎหมายกฎหมายแนวนอน (ครอบคลุมระบบ AI ทุกรูปแบบ)กฎระเบียบแนวตั้ง (มุ่งเน้นบริการ Generative AI โดยเฉพาะ)
การแบ่งระดับความเสี่ยง4 ระดับ (ยอมรับไม่ได้ / สูง / จำกัด / น้อยมาก)2 ระดับ (เกี่ยวข้องกับความมั่นคงทางความคิดเห็นสาธารณะ / การใช้งานเชิงพาณิชย์ทั่วไป)
จังหวะการกำกับดูแลเชิงรุก (ต้องจดทะเบียนตั้งแต่ขั้นตอนพัฒนา)เชิงรับ (จดทะเบียนหลังเปิดให้บริการ + จดทะเบียนอัลกอริทึม)
ความโปร่งใสสูง (กำหนดให้เปิดเผยสรุปแหล่งที่มาของข้อมูลฝึกฝนและโมเดลการ์ด)ปานกลาง (กำหนดให้ข้อมูลที่ใช้ฝึกต้องปฏิบัติตามข้อกำหนด แต่ไม่บังคับเปิดเผยแหล่งที่มา)
เพดานบทลงโทษ7% ของรายได้ทั่วโลก หรือ 35 ล้านยูโรระงับบริการ / ปรับ (โดยปกติเป็นจำนวนเท่าของรายได้ที่ได้จากการกระทำผิด)
ขอบเขตการบังคับใช้องค์กรทั้งหมดที่เข้าข่ายเกณฑ์รายได้ทั่วโลกผู้ให้บริการทุกรายที่ให้บริการภายในอาณาเขตจีน

ในทางปฏิบัติ ระบบ AI ของสถาบันการเงินในจีนมักอยู่ภายใต้กฎระเบียบสามชุดพร้อมกัน——《กฎระเบียบการบริหารจัดการ AI เชิงสร้างสรรค์》(ชั้นพื้นฐาน) + 《กฎระเบียบการบริหารจัดการสินเชื่อออนไลน์ของธนาคารพาณิชย์》(ชั้นธุรกิจ) + มาตรฐานการป้องกันข้อมูลหลายระดับ (MLPS) ระดับ 3 (เทียบเท่ามาตรฐาน MLPS Level 3 — Multi-Level Protection Scheme ของจีน สำหรับการทดสอบและรับรองความปลอดภัยของระบบสารสนเทศ) + การจดทะเบียนอัลกอริทึม (ชั้นการปฏิบัติตามข้อกำหนด) ซึ่งหมายความว่าการทำระบบขับเคลื่อนด้วยมาตรฐาน (spec-driven) ในจีนไม่สามารถลอกกรอบ EU AI Act มาใช้ตรงๆ ได้ แต่ต้องเขียนเส้นทางสามสายของจีน — “ความสอดคล้องของคลังข้อมูล + การจดทะเบียนอัลกอริทึม + การรายงานตามข้อกำหนด” ลงในไฟล์ CLAUDE.md ให้ครบถ้วน

หมายเหตุสำหรับผู้อ่านชาวไทย: ในประเทศไทย สถาบันการเงินอยู่ภายใต้กรอบกฎหมายที่แตกต่างออกไป — พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) บังคับใช้โดยสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC), พ.ร.บ. ว่าด้วยการรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562 (Cybersecurity Act) กำกับดูแลโดยสำนักงานคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ (NCSA) สำหรับโครงสร้างพื้นฐานสำคัญ, และ แนวปฏิบัติ AI Governance Guideline ของ ETDA (2567) เป็น soft law สำหรับการกำกับดูแล AI โดยไม่มีระบบจัดระดับการป้องกันเทียบเท่า — ธนาคารไทยจึงใช้ ISO 27001 แทน

สำหรับองค์กรที่ขยายตลาดต่างประเทศ: องค์ประกอบสี่อย่างของ EU AI Act อย่าง “การจัดการความเสี่ยง + การกำกับดูแลข้อมูล + ความโปร่งใสด้านเอกสาร + การกำกับดูแลโดยมนุษย์” คือทิศทางที่หน่วยงานกำกับดูแลของจีนกำลังปรับให้สอดคล้องทีละขั้น—ในปี 2025 ข้อเสนอแนะจากการจดทะเบียน AI เชิงสร้างสรรค์ของสำนักงานคณะกรรมการกิจการอินเทอร์เน็ตแห่งชาติ (CAC) สะท้อนให้เห็นถึงการหยิบยืม granularity จากฝั่งยุโรปอย่างชัดเจนแล้ว การเขียนมาตรฐานที่เข้ากันได้กับ EU AI Act ในวันนี้ มีแนวโน้มสูงที่จะสอดคล้องกับแนวโน้มการกำกับดูแลที่เข้มงวดขึ้นของจีนในอีก 3 ปีข้างหน้า (ประกาศการจดทะเบียนของ CAC ปี 2025–2026; eu-ai-act compliance มิ.ย. 2026)

เจ็ด: ข้อคิดสำหรับผู้บริหาร

ข้อคิดที่หนึ่ง: การเขียนไฟล์มาตรฐานโปรเจกต์ CLAUDE.md/AGENTS.md คือการลงทุนทางวิศวกรรมที่ให้ผลตอบแทนสูงสุดในยุค AI

ข้อคิดที่ 2: การขับเคลื่อนด้วยมาตรฐานคือความสามารถขององค์กร ไม่ใช่แค่การเลือกเครื่องมือ

คุณจะเลือก GitHub Spec Kit หรือ Claude Code ไม่ใช่ประเด็นสำคัญ สิ่งสำคัญคือคุณได้นิยามหรือยังว่า “องค์กรของเราจะทำงานร่วมกับ AI อย่างไร” หากยังไม่มีคำตอบนี้ ต่อให้เครื่องมือดีแค่ไหน ก็มีแต่จะทำให้ทีมสร้างหนี้ทางเทคนิคได้เร็วขึ้นเท่านั้น

ข้อคิดที่ 3: เขียนมาตรฐานลงในกระบวนการขององค์กร อย่าพึ่งพาตัวบุคคล

หากมาตรฐานอยู่ในหัวของวิศวกรอาวุโสเพียงไม่กี่คน พอคนย้ายออกไป มาตรฐานก็หายไปด้วย ต้องฝังมาตรฐานลงในเอกสารใน repository, CI gate, shared configuration ของทีม และแพลตฟอร์มการกำกับดูแลด้านเอเจนต์ (agent governance) ให้มาตรฐานกลายเป็นสินทรัพย์ขององค์กร ไม่ใช่ทักษะของปัจเจกบุคคล ที่ Atos มีเอเจนต์ 19,000 ตัวทำงานได้ครอบคลุม 54 ประเทศ เพราะการกำกับดูแลไม่ได้ขึ้นอยู่กับว่า “ใครสักคนเข้าใจ” แต่เป็นเพราะ “ระบบบังคับใช้”

ข้อคิดที่ 4: การมี gate ควบคุมสำคัญกว่าความเร็ว

เกตควบคุม 5 ขั้นตอนของ GitHub Spec Kit, หลักการ “ไม่เขียนโค้ดก่อนที่เทสต์จะล้มเหลว” ของ Superpowers, และ “ไม่เขียน spec ก็เริ่มไม่ได้” ของ Kiro ต่างก็เป็นการเพิ่ม “เบรก” ระหว่าง AI กับผลลัพธ์สุดท้ายทั้งสิ้น ยิ่งความสามารถของ AI สูงขึ้น การกำกับดูแลยิ่งต้องมาก่อน อัตราการเกิดเหตุการณ์ผิดปกติ 78% ในรายงาน New Relic 2026 คือราคาที่ทีม 62% ที่ “ส่งงานโดยไม่ตรวจทาน” ต้องจ่าย CIO ในอุตสาหกรรมการเงินเข้าใจเรื่องนี้ดีที่สุด: คณะกรรมการอนุมัติการเปลี่ยนแปลง (Change Advisory Board), กระบวนการจดทะเบียนอัลกอริทึม และการประเมิน Cybersecurity Act ล้วนเป็นการตั้งด่านก่อนเข้าสู่การผลิตจริง โค้ดที่เขียนโดย AI ก็ต้องการด่านที่คล้ายกัน และต้องตั้งให้เร็วกว่าด้วย

การตรวจสอบย้อนกลับ (ตอบตามตรง อย่าตกแต่ง): โค้ดที่ AI สร้างขึ้นในองค์กรของคุณ ถูกตีกลับจากการตรวจสอบ compliance บ่อยแค่ไหน? ครั้งล่าสุดที่โค้ด AI ก่อปัญหาคืออะไร? ถ้าคุณถามหัวหน้าฝ่ายเทคนิคว่า “เราทำงานร่วมกับ AI อย่างไร” เขาจะหยิบเอกสารออกมาได้ไหม? ถ้าตอบไม่ได้แม้แต่ข้อเดียวจากสามข้อนี้ แสดงว่าการขับเคลื่อนด้วยมาตรฐานยังไม่ปักหลัก——เขียนมาตรฐานก่อน แล้วค่อยซื้อเครื่องมือ

คำถามแบบโค้ชสำหรับผู้บริหาร

ทิ้งคำถามสามข้อไว้ตอนท้าย——ไม่ใช่เช็คลิสต์ แต่เป็นจุดเริ่มต้นที่คุณสามารถหยิบไปใช้ในการพูดคุยกับทีมได้ทันที:

  1. “หากพรุ่งนี้เครื่องมือ AI ทั้งหมดหยุดให้บริการ คุณภาพโค้ดของทีมคุณจะลดลงมากแค่ไหน?” — คำถามนี้เผยให้เห็นคุณค่าที่แท้จริงของการขับเคลื่อนด้วยมาตรฐาน (spec-driven): หากคำตอบคือ “ลดลงอย่างมีนัยสำคัญ” แสดงว่ามาตรฐานของคุณยังไม่ได้ถูกหลอมรวมเป็นส่วนหนึ่งของกระบวนการ หากคำตอบคือ “แทบไม่เปลี่ยนแปลง” แสดงว่าการขับเคลื่อนด้วยมาตรฐานกำลังทำงานได้จริง
  2. “ในโปรเจกต์ขับเคลื่อนด้วยมาตรฐานของคุณ ฝ่าย compliance เป็น ‘ยามเฝ้าประตู’ หรือ ‘enabler’?” — หากคำตอบคือ “ยามเฝ้าประตู” ความเร็วในการส่งมอบของคุณจะถูกคอขวดจากการอนุมัติ หากคำตอบคือ “enabler” แสดงว่าคุณเดินมาถูกทางตามแนวทางในหัวข้อ 5.2 แล้ว
  3. “อีก 12–18 เดือนข้างหน้า ขนาดทีมของคุณจะเปลี่ยนไปอย่างไร?” — คำตอบจากรายงาน Microsoft WTI 2026 คือผู้นำ 82% จะใช้ AI agent เพื่อ “ขยาย” กำลังคน หากคำตอบของคุณคือ “ไม่เปลี่ยนแปลง” แสดงว่าธุรกิจคุณไม่ได้เติบโต หรือองค์กรของคุณยังไม่ได้ออกแบบให้รับประโยชน์จากการขับเคลื่อนด้วยมาตรฐาน

คำถามสามข้อนี้ไม่มีคำตอบที่ถูกต้องตายตัว แต่ทิศทางของคำตอบสำคัญกว่าตัวคำตอบเสียอีก

ขั้นตอนถัดไป

นี่คือบทความที่หกในซีรีส์ “การเปลี่ยนแปลงวิศวกรรมซอฟต์แวร์ในยุค AI” เราเดินทางจาก Conway’s Law (โครงสร้างองค์กรกำหนดสถาปัตยกรรม) ไปสู่ Team Topologies (วิธีออกแบบองค์กร) ต่อด้วยการย้ายคอขวด (คอขวดอยู่ที่การตรวจสอบ ไม่ใช่การเขียนโค้ด) และวันนี้เรามาถึงการขับเคลื่อนด้วยมาตรฐาน (ใช้เอกสารเพื่อกำกับพฤติกรรมของ AI)

ในบทความถัดไป (ตอนที่ 7) เราจะพาไปดูโครงสร้างพื้นฐานเบื้องล่างที่คอยรองรับทุกอย่างที่กล่าวมา——โปรโตคอล MCP (Model Context Protocol) ว่าทำไมโปรโตคอลโอเพนซอร์สจาก Anthropic ถึงถูกขนานนามว่า “USB-C แห่งวงการ AI” ทำไม OpenAI, Google และ Microsoft ถึงแห่กันตามรอย และมันทำให้เครื่องมือหลายตัวและเอเจนต์หลายตัวทำงานร่วมกันได้อย่างไร

อยากนำกรอบแนวคิดนี้ไปปรับใช้กับองค์กรของคุณจริง ๆ หรือ?

เมื่อแนวคิดแบบ “regulation-driven” เริ่มถูกนำเข้ามาใช้ในองค์กร สิ่งที่ต้องแก้จริง ๆ มักจะวนกลับมาที่คำถามเฉพาะเจาะจงไม่กี่ข้อ: กฎหลักจะถูกบันทึกลงใน CLAUDE.md / AGENTS.md อย่างไร โค้ดเดิมที่มีอยู่จะถูกปรับให้เข้าตามมาตรฐานได้ยังไง การฝัง compliance เข้าไปในกระบวนการทำอย่างไร และตัวชี้วัดอะไรที่ใช้รับรองผลของโปรเจกต์นำร่อง

ปัจจุบันเรามีความร่วมมือสามรูปแบบด้วยกัน:

  • อบรมภายในองค์กร (Enterprise Training): นำโปรเจกต์จริงของบริษัทคุณมาวิเคราะห์ร่วมกัน ครอบคลุมการจัดทำเอกสารมาตรฐาน การออกแบบ CI gate การฝัง compliance เข้าไปในกระบวนการ และการวางโครงสร้างการกำกับดูแล
  • ให้คำปรึกษาเฉพาะด้าน (Advisory): โฟกัสที่การตัดสินใจใดการตัดสินใจหนึ่งโดยเฉพาะ เช่น “บริษัทเราควรเขียน CLAUDE.md / AGENTS.md ก่อนไหม” หรือการจัดลำดับความสำคัญในการปรับปรุงโค้ดเดิมให้สอดคล้องกับข้อกำหนด
  • เสวนาสำหรับผู้บริหารและงานสัมมนา (Executive Sessions & Talks): ครอบคลุมหัวข้อเครื่องมือเขียนโค้ดด้วย AI, แนวคิด regulation-driven, การกำกับดูแลองค์กร และกลุ่มบริษัท Frontier Firms

บทความนี้สามารถนำเสนอกรอบแนวคิดทั่วไปได้ แต่การนำไปปฏิบัติจริงยังคงต้องออกแบบใหม่โดยอิงตามข้อกำหนดด้าน compliance ขอบเขตด้านกฎระเบียบ ความพร้อมทางวิศวกรรม และกระบวนการส่งมอบงานที่มีอยู่ของแต่ละองค์กร หากสนใจความร่วมมือ สามารถติดต่อได้ที่ coach@iaiuse.com

อ่านเพิ่มเติม: 《คู่มือวิธีคิดแบบเห็นป้าย v1.0》(เรียนรู้ AI อย่างช้าๆ 187) ซึ่งแนะนำกรอบแนวคิด 7 ขั้นตอนสำหรับการเปลี่ยนผ่านดิจิทัลขององค์กร

เกี่ยวกับซีรีส์นี้

“การเปลี่ยนแปลงวิศวกรรมซอฟต์แวร์ในยุค AI” เป็นซีรีส์งานวิจัยสำหรับ CIO, CDO, CTO และผู้บริหารฝ่ายดิจิทัลในอุตสาหกรรมโทรคมนาคม การเงิน การผลิต และอีคอมเมิร์ซ จำนวนทั้งสิ้น 18 ตอน มุ่งเน้นการวิเคราะห์ผลกระทบของเครื่องมือเขียนโค้ดด้วย AI, การขับเคลื่อนด้วยมาตรฐาน และธรรมาภิบาลองค์กร ที่มีต่อกระบวนการส่งมอบซอฟต์แวร์ โครงสร้างองค์กร และความพร้อมทางวิศวกรรม

ซีรีส์นี้ติดตามบทความวิชาการ เอกสารจากผู้จำหน่าย และรายงานอุตสาหกรรมอย่างต่อเนื่อง โดยคลังงานวิจัยสะสมมีมากกว่า 200 ชิ้น และมีการระบุระดับหลักฐานสำหรับข้อสรุปสำคัญ เพื่อแยกแยะระหว่างข้อเท็จจริงที่ได้รับการพิสูจน์แล้ว ข้ออ้างจากผู้จำหน่าย ข้อสังเกตจากอุตสาหกรรม และการคาดการณ์ของผู้เขียน

ผู้เขียนมีประสบการณ์ด้านที่ปรึกษาและการวิเคราะห์ธุรกิจในองค์กรขนาดใหญ่มาเกือบ 8 ปี เคยทำงานที่ IBM และมีส่วนร่วมในโครงการที่เกี่ยวข้องกับโทรคมนาคม การเงิน ประกันภัย และการผลิต หลังจากนั้น ยังคงทำงานในแนวหน้าของการพัฒนาผลิตภัณฑ์สำหรับผู้ให้บริการเครือข่าย ผลิตภัณฑ์อินเทอร์เน็ต และแอปพลิเคชัน AI ในด้านการวิเคราะห์ความต้องการ การออกแบบผลิตภัณฑ์ และการนำไปปฏิบัติจริงข้ามทีม

ซีรีส์นี้เกี่ยวกับการตัดสินใจเรื่องการกำกับดูแลด้วยมาตรฐาน การจัดระเบียบองค์กร และวิศวกรรม ล้วนมาจากการปฏิบัติจริง ผนวกกับงานวิจัยสาธารณะและกรณีศึกษาจากอุตสาหกรรมเพื่อการตรวจสอบข้ามแหล่งที่มา เนื้อหาที่เกี่ยวข้องกับโครงการเฉพาะได้ถูกทำให้ไม่ระบุตัวตนแล้ว ส่วนบางสถานการณ์ในอุตสาหกรรมเป็นการจำลองปัญหาทั่วไป โดยมีแหล่งอ้างอิงท้ายบทความ

เบื้องหลังเพจนี้จริงๆ แล้วคือทีมเล็กๆ — ฉันกับเพื่อนร่วมงาน 1-2 คนที่ทำงานด้วยกันมานาน แบ่งหน้าที่กันรับผิดชอบงานวิจัยเครื่องมือเขียนโค้ดด้วย AI การจัดทำกรณีศึกษาด้านการกำกับดูแลองค์กร และการสนทนาแบบโค้ช โครงการส่วนใหญ่ที่เราพูดถึงว่า “เราเดินผ่านไปพร้อมกับองค์กรลูกค้า” นั้น เป็นงานที่เราหลายคนร่วมกันส่งมอบจริง อย่างไรก็ตาม ยังคงไม่เอ่ยชื่อลูกค้าหรือบุคคลใดๆ เพื่อรักษาขอบเขตด้านการปฏิบัติตามข้อกำหนด และการไม่เปิดเผยตัวตนยังคงไว้เพื่อเปิดพื้นที่ให้เพื่อนร่วมงานในอนาคต

แหล่งอ้างอิง (ผ่านการตรวจสอบแล้วทั้งหมด พร้อมระบุระดับหลักฐานทีละรายการ)

  • CodeRabbit (2025.12). State of AI vs Human Code Generation Report. ปัญหาในโค้ดที่เขียนโดย AI สูงกว่าโค้ดที่เขียนโดยมนุษย์ถึง 1.7 เท่า (10.83 ต่อ 6.45 ปัญหา/PR) โดยแบ่งเป็นด้านตรรกะ/ความถูกต้อง 1.75 เท่า คุณภาพโค้ด 1.64 เท่า ความปลอดภัย 1.57 เท่า การจัดการรหัสผ่าน 1.88 เท่า และ XSS 2.74 เท่า ระดับหลักฐาน: ระดับที่ 1 ที่มา: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263

  • The Register (2025.12.17). รายงานสรุปผลจากรายงานของ CodeRabbit: วิเคราะห์ open-source PR จำนวน 470 รายการ พบว่า PR ที่เขียนร่วมกับ AI มีปัญหาเฉลี่ย 10.83 จุด เทียบกับ 6.45 จุดสำหรับ PR ที่เขียนโดยมนุษย์ล้วน ระดับหลักฐาน: ระดับที่ 2 ที่มา: URL เดียวกับข้างต้น

  • CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap” — ปี 2026 เป็นปีเปลี่ยนผ่านจากการ “เร่งความเร็วในการสร้างโค้ด” ไปสู่ “คุณภาพโค้ดและการกำกับดูแล” ระดับหลักฐาน: ระดับที่ 2 ที่มา: https://tfir.io/ai-code-quality-2026-guardrails

  • New Relic (2026). The 2026 State of AI Coding Report. 78% ของทีมพบว่ามีเหตุการณ์ผิดพลาดหลังนำโค้ด AI ขึ้นใช้งานมากขึ้น; 62% ของผู้บริหารด้านเทคนิคยอมรับว่าทีมของตน “ปล่อยโค้ด AI โดยไม่ตรวจสอบอย่างมั่นใจ”; 96% เห็นว่าการสังเกตการณ์ได้ (observability) เป็นสิ่งจำเป็น ระดับหลักฐาน: ระดับที่ 1 (รายงานจากผู้จำหน่าย) ที่มา: https://newrelic.com/resources/report/2026-state-of-ai-coding

  • Microsoft 2026 Work Trend Index Annual Report (2026.5.5). กลุ่มตัวอย่างคือพนักงานที่ใช้ AI จำนวน 20,000 คน จาก 10 ประเทศ โดย 82% ของผู้บริหารวางแผนจะขยายกำลังคนด้วย AI agent ภายใน 12–18 เดือนข้างหน้า ขณะที่ 81% คาดว่า AI agent จะถูกผสานการทำงานในระดับปานกลางถึงสูง และ 24% เริ่มใช้งานในระดับองค์กรแล้ว นอกจากนี้ 49% ของการสนทนาผ่าน Copilot ช่วยสนับสนุนงานด้านการคิดวิเคราะห์ ส่วน 58% ของผู้ใช้ AI กล่าวว่าตนทำสิ่งที่ “เมื่อปีก่อนทำไม่ได้” และตัวเลขนี้เพิ่มขึ้นเป็น 80% ในกลุ่ม Frontier Professionals ระดับหลักฐาน: ระดับที่ 1 ที่มา: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf

  • Microsoft FY26 Retrospective: จาก AI ทดลอง สู่การเปลี่ยนผ่านระดับแนวหน้า (28 ก.ค. 2026). EY นำ Microsoft 365 Copilot ไปใช้กับพนักงาน 150,000 คน ประหยัดเวลาได้ 2.5 ล้านชั่วโมง คิดเป็นมูลค่าประมาณ 250 ล้านดอลลาร์สหรัฐ; ขยายผลไปยังพนักงาน 400,000 คนทั่วโลก พบว่าทำงานเร็วขึ้น 95% ต้นทุนฝ่ายการเงินลดลง 37% และเวิร์กโฟลว์ที่ทำด้วยมือลดลงสูงสุด 90% ส่วน Atos ปรับใช้ Copilot กับพนักงาน 56,000 คนใน 56 ประเทศ พร้อม AI agent 19,000 ตัว ภายใต้ระนาบควบคุมกลางด้าน identity ความปลอดภัย compliance และ governance ระดับหลักฐาน: ระดับที่ 1 (รีวิวอย่างเป็นทางการโดย Microsoft) ที่มา: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • ความร่วมมือเชิงกลยุทธ์ระหว่าง Atos Group และ Microsoft (9 มิ.ย. 2026). Atos ปรับใช้ Microsoft 365 E7 (Frontier Suite) ครอบคลุมพนักงาน 56,000 คนใน 56 ประเทศ พร้อม AI agent จำนวน 19,000 ตัว โดยรวมศูนย์การจัดการไว้ที่ Entra/Defender/Intune/Purview/Agent 365 ระดับหลักฐาน: ระดับที่หนึ่ง (ข่าวประชาสัมพันธ์ร่วมของทั้งสองฝ่าย) ที่มา: 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 (เปิดซอร์ส 2025.9, พัฒนาต่อเนื่อง H1 2026). เกตเวย์ 5 ขั้นตอน /speckit.constitution → /specify → /plan → /tasks → /implement พร้อมด้วย /clarify และ /analyze; ทำงานแบบโมเดลอิสระ (รองรับทั้ง Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code) ระดับหลักฐาน: ระดับที่หนึ่ง ที่มา: https://github.com/github/spec-kit

  • AWS Kiro (เปิดตัว 2025.7, พัฒนาต่อเนื่อง H1 2026). เวิร์กโฟลว์สามขั้นตอน: ความต้องการ → การออกแบบ → งาน; spec จะทริกเกอร์การทำงานอัตโนมัติของเอเจนต์ที่กำหนดไว้ล่วงหน้า; หากไม่เขียน spec จะไม่สามารถเริ่มต้นได้ ระดับหลักฐาน: ระดับที่หนึ่ง ที่มา: https://kiro.dev/

  • OpenAI Codex + AGENTS.md + Skills (2025-2026). Codex 2026.6 มีผู้ใช้รายสัปดาห์กว่า 5 ล้านคน โดย 20% เป็นกลุ่มที่ไม่ใช่นักพัฒนา; AGENTS.md + Skills เป็นชุดคำสั่งที่ประกอบรวมกันได้ ระดับหลักฐาน: ระดับหนึ่ง (ประกาศอย่างเป็นทางการจาก OpenAI) ที่มา: https://developers.openai.com/codex/skills

  • Claude Code (Anthropic, 2026 H1). ระบบ CLAUDE.md + .claude/rules/ + Skills; เข้าสู่ตลาดอย่างเป็นทางการของ Anthropic ในเดือนก.พ. 2026; คลัง Skills บน GitHub มี 11.2 หมื่น stars; รอบ G เมื่อเดือนก.พ. 2026 เปิดเผยรายได้ต่อปี 2.5 พันล้านดอลลาร์ ระดับหลักฐาน: ระดับหนึ่ง ที่มา: https://code.claude.com/docs/en/claude-directory

  • JetBrains AI Pulse Survey (2026.1). สำรวจนักพัฒนามืออาชีพกว่า 10,000 คนทั่วโลก ใน 8 ภาษา; Claude Code ได้คะแนน CSAT 91% / NPS 54 (สูงสุดในอุตสาหกรรม); อัตราการนำ Claude Code ไปใช้ในที่ทำงาน 18% (เพิ่มขึ้น 6 เท่าจาก 3% ใน 9 เดือน) ขณะที่อเมริกาเหนืออยู่ที่ 24%; Copilot มีอัตราการนำไปใช้ในที่ทำงาน 29% แต่การเติบโตหยุดชะงัก; Cursor 18% ระดับหลักฐาน: ระดับที่ 1 ที่มา: https://www.jetbrains.com/lp/tools/ai-tools/

  • Pragmatic Engineer Newsletter (2026.2). สำรวจนักพัฒนา 15,000 คน; 46% เลือก Claude Code เป็น “เครื่องมือที่ชื่นชอบมากที่สุด” ขณะที่ Cursor ได้ 19% และ Copilot ได้ 9% ระดับหลักฐาน: ระดับที่ 1 ที่มา: https://newsletter.pragmaticengineer.com/

  • Alibaba Qoder (ส.ค. 2025 → ก.ค. 2026). เปิดตัวโดย Alibaba ในเดือนส.ค. 2025; วันที่ 15 พ.ค. 2026 Qoder 1.0 อัปเกรดเป็น Autonomous Agent Development Workbench; ประกอบด้วย Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; วันที่ 28 พ.ค. 2026 เปิดตัว Cloud Agents (runtime สำหรับเอเจนต์ที่โฮสต์โดยสมบูรณ์); วันที่ 21 ก.ค. 2026 เปิดตัว Qoder Security; เดือนพ.ค. 2026 มีผู้ใช้ทั่วโลกเกิน 5 ล้านราย; รองรับการผสานกับ DingTalk CLI; วันที่ 20 พ.ค. 2026 เปลี่ยนชื่อจาก Tongyi Lingma เป็น Qoder CN ระดับหลักฐาน: ระดับที่ 1 แหล่งที่มา: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525

  • vibecoding.app / thebcms.com / tfir.io (ครึ่งปีแรก 2026). คำสั่งแบบห้าขั้นตอนของ Spec Kit, บทวิจารณ์เปรียบเทียบเครื่องมือ SDD, วิธีการเขียนข้อกำหนดแบบ EARS ระดับหลักฐาน: ระดับที่สอง (การประเมินโดยบุคคลที่สาม) แหล่งที่มา: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development

  • EU AI Act / Code of Practice (มีผลบังคับใช้เต็มรูปแบบ 2 ส.ค. 2026) ระบบ AI ความเสี่ยงสูงต้องปฏิบัติตามข้อกำหนดภายใน 2 ส.ค. 2026; โมเดล GPAI ที่มีอยู่แล้วขยายเวลาไปถึง 2 ส.ค. 2027; ค่าปรับสูงสุด 35 ล้านยูโรหรือ 7% ของรายได้ทั่วโลก; มาตรา 9-15 ครอบคลุมการบริหารความเสี่ยง การกำกับข้อมูล ความโปร่งใสด้านเอกสาร การกำกับดูแลโดยมนุษย์ และความแม่นยำ/ความทนทาน ระดับหลักฐาน: ระดับที่ 1 (กฎหมาย + การวิเคราะห์การปฏิบัติตามข้อกำหนดระดับรอง) แหล่งอ้างอิง: 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) 44% ของปัญหาที่พบมีต้นตอมาจากการขาดบริบทหรือข้อมูลแวดล้อม ระดับหลักฐาน: ระดับที่ 2 (รายงานจากผู้จำหน่าย) แหล่งอ้างอิง: https://www.qodo.ai/reports/state-of-ai-code-quality/

เรียนรู้ AI อย่างช้าๆ

บทนำ

ในยุคที่เทคโนโลยี AI กำลังเปลี่ยนแปลงอุตสาหกรรมต่างๆ อย่างรวดเร็ว CIO และผู้นำธุรกิจต่างๆ ต้องเตรียมตัวให้พร้อมในการนำ AI ไปใช้ในการดำเนินธุรกิจของตนเอง

IAIUSE เป็นหน่วยงานที่ให้คำปรึกษาที่มีประสบการณ์ในการนำ AI ไปใช้ในอุตสาหกรรมต่างๆ เช่น เทคโนโลยีสารสนเทศ การเงิน การผลิต และการค้าออนไลน์

ตัวอย่างการใช้งาน AI ในอุตสาหกรรมต่างๆ

  • โทรคมนาคม : AT&T ใช้ AI เพื่อปรับปรุงการบริการลูกค้าโดยใช้ระบบการเรียนรู้ของเครื่อง (Machine Learning) เพื่อระบุและแก้ไขปัญหาที่เกิดขึ้น
  • ธนาคาร : Deutsche Telekom ใช้ AI เพื่อตรวจสอบและป้องกันการฉ้อโกงทางการเงินโดยใช้ระบบการวิเคราะห์ข้อมูล (Data Analysis)
  • การผลิต : NTT ใช้ AI เพื่อปรับปรุงกระบวนการผลิตโดยใช้ระบบการเรียนรู้ของเครื่อง (Machine Learning) เพื่อระบุและแก้ไขปัญหาที่เกิดขึ้น
  • การค้าออนไลน์ : Vodafone ใช้ AI เพื่อปรับปรุงการบริการลูกค้าโดยใช้ระบบการเรียนรู้ของเครื่อง (Machine Learning) เพื่อระบุและแก้ไขปัญหาที่เกิดขึ้น

การเตรียมตัวในการนำ AI ไปใช้

  • การฝึกอบรม : CIO และผู้นำธุรกิจต่างๆ ต้องฝึกอบรมให้พร้อมในการนำ AI ไปใช้ในการดำเนินธุรกิจของตนเอง
  • การวางแผน : CIO และผู้นำธุรกิจต่างๆ ต้องวางแผนการนำ AI ไปใช้ในการดำเนินธุรกิจของตนเอง
  • การตรวจสอบ : CIO และผู้นำธุรกิจต่างๆ ต้องตรวจสอบและประเมินผลการนำ AI ไปใช้ในการดำเนินธุรกิจของตนเอง

แหล่งข้อมูล

  • IAIUSE
  • AT&T
  • Deutsche Telekom
  • NTT
  • Vodafone
]]> โค้ด AI มีปัญหา 1.7 เท่า ช่องโหว่ 2.74 เท่า—AI มองไม่เห็นกฎของคุณ ห้าแพลตฟอร์ม H1 2026 หันสู่แนวทาง spec-driven Spec-Driven Development — Viết đặc tả là hành động kỹ thuật có ROI cao nhất trong kỷ nguyên AI — Cuộc cách mạng kỹ thuật phần mềm thời AI — Học AI từ từ 177 https://iaiuse.com/vi/posts/spec-driven-development-viet-chuan-la-hanh-dong-roi-cao-nhat-thoi-ai-cuoc-cach-mang-ky-thuat-phan-mem-thoi-ai 2026-04-11T10:00:00.000Z 2026-08-11T00:00:00.000Z

Nguồn dữ liệu trong bài: CodeRabbit 2025.12 / New Relic 2026 report, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms announcement, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. Các tình huống được tổng hợp mang tính đại diện, không chỉ đến một doanh nghiệp cụ thể nào.

Sai lầm lớn nhất của bạn không phải là không mua công cụ, mà là không viết CLAUDE.md

Một CIO của ngân hàng cổ phần từng than phiền với tôi: công cụ AI thì mua rồi, mô hình thì triển khai rồi, người cũng đào tạo xong, vậy mà cả nửa đầu năm 2026, vòng giao hàng gần như không nhúc nhích. Trưởng nhóm hệ thống lõi nói thẳng hơn: “Code AI viết ra dùng được, nhưng lần nào cũng phải viết lại từ đầu — vì nó không hiểu quy định nội bộ của ngân hàng mình, không hiểu yêu cầu pháp lý, cũng không biết cách kết nối với cái hệ thống cũ 30 năm tuổi đó.”

Vấn đề không nằm ở chỗ AI chưa đủ mạnh, mà nằm ở chỗ các anh chưa viết ra quy tắc. Phân tích của CodeRabbit trên 470 pull request mã nguồn mở vào tháng 12/2025 đưa ra một bộ số liệu được trích dẫn rộng rãi: PR có AI cộng tác trung bình chứa 10,83 vấn đề, PR thuần thủ công là 6,45 — gấp 1,7 lần, tức nhiều hơn 70% bug so với làm tay. Đến năm 2026, câu chuyện vẫn chưa có bước ngoặt: New Relic trong 2026 State of AI Coding Report phát hiện 78% đội ngũ báo cáo nhiều sự cố hơn sau khi đưa code AI lên môi trường production, và 62% lãnh đạo kỹ thuật thừa nhận đội của họ “tự tin merge code AI mà không review từng dòng” (báo cáo chính thức New Relic 2026, score 0,866, nguồn cấp một). Hai bộ số liệu này nói về cùng một chuyện — AI không thiếu năng lực, mà thiếu ngữ cảnh.

Tại thời điểm tháng 8/2026 này, mọi câu chuyện về “tăng tốc chuyển đổi AI” đều phải được đặt trong một phép đối chiếu:

| Phe đảng | Tiến triển (H1 2026) | Phản ví dụ (H1 2026) |
|—|—|—|—|
| EY | Microsoft 365 Copilot triển khai cho 150.000 nhân viên, tiết kiệm 2,5 triệu giờ / 250 triệu USD; mở rộng lên 400.000 nhân viên toàn cầu | Đồng thời thừa nhận mức tăng tốc 95% và giảm 37% chi phí vận hành tài chính chỉ đạt được khi “chuẩn hóa quy trình đi trước” |
| Atos | Triển khai tại 54 quốc gia / 56.000 nhân viên; đồng thời vận hành 19.000 AI agent, với mặt phẳng điều khiển thống nhất cho danh tính/bảo mật/tuân thủ/quản trị | Kiên định nguyên tắc “đưa năng lực quản trị của Agent 365 lên trước, rồi mới mở rộng quy mô” |
| Chính Microsoft | Work Trend Index 2026: 82% nhà lãnh đạo dự định mở rộng lực lượng lao động bằng AI agent trong vòng 12-18 tháng | Cùng kỳ thừa nhận “nhịp độ thay đổi tổ chức tụt hậu so với mức độ sử dụng cá nhân” — đây chính là mâu thuẫn cốt lõi trong khái niệm Frontier Firm |

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

Hai nhóm dữ liệu đối chiếu này cho thấy một điều: không có chuẩn mực, mở rộng quy mô đồng nghĩa với việc nhân rủi ro lên N lần. Cái “nhanh” của EY/Atos/Microsoft không phải là model nhanh, mà là “tổ chức đã trả lời xong câu hỏi dùng AI như thế nào trước khi bắt tay vào làm”. Đây chính là bối cảnh khiến Spec-Driven Development (SDD, phát triển định hướng đặc tả) thực sự trở thành xu hướng chủ đạo trong nửa đầu 2026 — không phải vì kỹ sư thích viết tài liệu, mà vì không viết đặc tả thì không thể sống sót trong môi trường có 19.000 agent.

Bài viết này làm rõ ba điều: 1) Vì sao lỗi trong code do AI tạo ra nghiêm trọng hơn code viết tay tới 1,7 lần; 2) Cách năm nền tảng GitHub, AWS, OpenAI, Anthropic, Alibaba cùng tiến về một mô hình chung trong nửa đầu 2026 — dùng tài liệu để ràng buộc hành vi của AI; 3) Vì sao định hướng đặc tả là năng lực tổ chức, không phải lựa chọn công cụ, cùng ba giai đoạn triển khai trong nửa đầu 2026.

Mã AI vs Mã con người: Phân bố lỗi (Phân tích 470 PR mã nguồn mở) Báo cáo CodeRabbit 2025.12 ｜ Tất cả các con số là AI / con người nhân với hệ số (đường cơ sở 1.0)

Độ dài thanh = Số lần lỗi AI nhân với con người; đường cơ sở 1.0× = mức độ con người

Đường cơ sở 1.0×

Tổng số vấn đề

1.7×
AI 10.83 vs Con người 6.45 / PR

Lỗi logic / chính xác

1.75×

Chất lượng mã / Khả năng bảo trì

1.64×

Phát hiện bảo mật (tổng hợp)

1.57×

Xử lý mật khẩu không đúng

1.88×

Lỗ hổng XSS

2.74×
↑ Cao nhất

Mã AI không có ràng buộc, mỗi chiều đều cao hơn con người
Tài chính / Viễn thông = Tuân thủ đối chiếu, quản lý mật khẩu, mã hóa trường nhạy cảm, AI không nhìn thấy

Phần 1: Tỷ lệ lỗi của AI không phải vấn đề của mô hình, mà là vấn đề về ngữ cảnh

Trong báo cáo của CodeRabbit có một câu từng được trích dẫn đi trích dẫn lại nhiều lần: “AI thiếu logic nghiệp vụ tại chỗ: mô hình suy luận mẫu code theo thống kê, chứ không phải theo hiểu biết ngữ nghĩa. Không có ràng buộc chặt chẽ, chúng sẽ bỏ sót những quy tắc hệ thống mà kỹ sư kỳ cựu đã nội tâm hóa.”

Câu nói này giải thích vì sao chính nền tảng lập trình AI của CodeRabbit (một công ty chuyên review code AI) lại sớm nhìn ra bộ số liệu này hơn người khác — họ mỗi ngày xem hàng nghìn PR, mỗi ngày xem code AI viết ra trông như thế nào. Phát hiện “then chốt nhất” không phải tổng số, mà là phân bố:

  • Logic/độ chính xác +75%: lỗi logic nghiệp vụ, lỗi quan hệ phụ thuộc, lỗi luồng điều khiển, lỗi cấu hình — những vấn đề này có khi không lộ ra trong test, nhưng lại gây sự cố trên môi trường production.
  • Chất lượng code +64%: đặt tên không nhất quán, cấu trúc không rõ ràng, vi phạm pattern của dự án — đây là “danh mục có khác biệt lớn nhất”. Kỹ sư kỳ cựu liếc qua là nhận ra ngay “đây không phải cách viết của chỗ mình”.
  • Bảo mật +57% (nhóm XSS cao nhất 2,74×): xử lý mật khẩu không đúng (1,88×), tham chiếu đối tượng không an toàn (1,91×), lộ thông tin nhạy cảm, deserialize không an toàn (1,82×) — trong ngành tài chính, đây không phải chuyện “có dùng được không”, mà là chuyện “có xuất bản được không”.

Vấn đề không nằm ở chỗ AI chưa đủ mạnh. Mà nằm ở chỗ nó không thấy được.

Vấn đề không nằm ở chỗ AI chưa đủ mạnh. Mà nằm ở chỗ nó không thấy được.

Quay lại điểm nghẽn thực sự của vị CIO kia, đây là ba lỗi cụ thể khi AI vận hành trong hệ thống lõi tài chính:

Thứ nhất, AI không thấy được logic đối soát 30 năm. Quy tắc quản trị rủi ro của ngân hàng nằm trong các stored procedure của hệ thống lõi — viết từ 30 năm trước, không ai còn nhớ hết. Code do AI sinh ra trông thì có vẻ ổn, nhưng khi chạy trên môi trường production sẽ kích hoạt đúng cái bước kiểm tra đối soát mà không ai còn nhớ, khiến cả lô giao dịch thất bại.

Thứ hai, AI không thấy được ràng buộc tuân thủ. Mật khẩu phải đi qua hệ thống quản lý khóa, trường nhạy cảm phải mã hóa khi lưu trữ, log không được in thông tin khách hàng — đây là ràng buộc cứng từ cơ quan quản lý, được ghi trong quy chế nội bộ. AI không biết những điều này, code viết ra chạy được nhưng không qua nổi vòng kiểm tra tuân thủ.

Thứ ba, AI không thấy được nợ kỹ thuật của bạn. Cái hệ thống legacy 30 năm đó dùng một bộ giao thức interface riêng, tài liệu đã thất lạc từ lâu. AI viết code theo chuẩn RESTful thông dụng, khi lên production mới phát hiện interface không khớp — làm lại mất hai tuần.

Quay lại một nhóm số liệu khác từ New Relic: 62% đội ngũ “tự tin phát hành code AI mà không review”, 78% báo cáo nhiều sự cố hơn sau khi đưa lên production. Hai con số này ghép lại với nhau, tương đương với một câu nói — tỷ lệ lỗi của code AI tự nó không phải là vấn đề; “tôi không biết code AI có lỗi gì” mới là vấn đề.

Tình huống điển hình: Một ngân hàng cổ phần tại Trung Quốc đưa AI vào hỗ trợ phát triển module quản lý rủi ro của hệ thống lõi. Trong vòng ba tháng, tỷ lệ hồ sơ bị từ chối ở khâu kiểm tra tuân thủ tăng rõ rệt, nguyên nhân chính nằm ở các quy tắc nội bộ như quản lý mật khẩu, mã hóa trường dữ liệu nhạy cảm, tuân thủ nhật ký hệ thống. Các quy tắc này đều được ghi trong tài liệu nội bộ, nhưng AI không đọc được. Sau đó, nhóm phát triển đã viết các quy tắc cốt lõi vào file CLAUDE.md, tỷ lệ bị từ chối giảm đáng kể.

Phần 2: Năm nền tảng lớn trong nửa đầu 2026: Cùng đích đến, “điều khiển bằng quy chuẩn”

Tháng 7/2025, GitHub ra mắt Spec Kit; đầu năm 2026, AWS Kiro, OpenAI Codex, Anthropic Claude Code đều đã bổ sung đầy đủ; tháng 5/2026, Alibaba Qoder đưa “Spec-Driven Workflow” vào định vị sản phẩm. Năm nền tảng lớn trong nửa đầu 2026 đã cùng tiến tới một mô hình chung — dùng tài liệu để ràng buộc hành vi của AI. Đây không phải phát minh của riêng công ty nào, mà là phản ứng tập thể của ngành trước “cuộc khủng hoảng chất lượng mã nguồn do AI tạo ra”.

Con đường dẫn dắt quy định của 5 nền tảng lớn (2025-2026 H1) GitHub Spec Kit Mở nguồn 2025.9 constitution.md Năm giai đoạn cổng điều khiển: constitution → specify → plan → tasks → implement Mô hình không liên quan, có thể kết nối 8+ đại lý Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md Ba giai đoạn làm việc: Yêu cầu → Thiết kế → Nhiệm vụ Spec-driven viết tiến trình làm việc IDE Hook kích hoạt tự động đại lý Tuân thủ / kiểm toán hook được chôn Không viết spec thì không thể khởi động OpenAI Codex 2025-2026 AGENTS.md + Hệ thống kỹ năng Bộ lệnh có thể kết hợp Cấu hình chia sẻ cấp độ nhóm 5M+ tuần hoạt động (2026.6) Người không phải nhà phát triển chiếm 20% Từ lập trình chuyển sang đại lý chung Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + Kỹ năng（Thị trường chính thức 2026.2） + MCP hệ sinh thái CSAT 91% / NPS 54 $2.5B ARR（2026.2） GitHub 11.2 nghìn ngôi sao Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Chế độ Quest thực hiện tự động + Chế độ Expert nhóm + RepoWiki ngữ cảnh 5M+ người dùng toàn cầu（2026.5） 2026.7.21 Qoder Security Đã kết nối CLI của DingTalk Thể thức chung：Quy chuẩn hóa hợp tác AI Để tất cả mọi người và tất cả các đại lý AI làm việc với cùng một quy chuẩn

Cùng xem từng nền tảng đã làm gì mới trong nửa đầu 2026:

GitHub Spec Kit: Bản tham chiếu, kiểm soát 5 giai đoạn. Ra mắt mã nguồn mở vào tháng 9/2025, đến nửa đầu 2026 đã trở thành bản triển khai tham chiếu của ngành. 5 lệnh cốt lõi + 2 lệnh bổ trợ: /speckit.constitution (nguyên tắc bất khả thương lượng), /speckit.specify (làm gì, tại sao), /speckit.plan (thay đổi thế nào), /speckit.tasks (chia nhỏ nhiệm vụ), /speckit.implement (thực thi), cùng với /clarify và /analyze. Điểm thiết kế mấu chốt là không phụ thuộc vào mô hình — cùng một bộ file spec/plan/tasks không bị ràng buộc với một agent thực thi cụ thể nào, mà Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf, Qwen Code đều có thể kết nối được. Điều này biến nó thành “giao thức SDD cấp tổ chức”, chứ không phải sản phẩm riêng của GitHub (theo đánh giá của vibecoding.app 6/2026, điểm 0.816, nguồn cấp hai).

AWS Kiro：Đưa chuẩn mực vào thẳng IDE. Ra mắt tháng 7/2025, đến H1/2026 phát triển thành một Agent IDE hoàn chỉnh. Quy trình làm việc ba giai đoạn: Yêu cầu → Thiết kế → Tác vụ. Điểm khác biệt so với Spec Kit nằm ở “cái móc” — file spec của Kiro có thể kích hoạt các hành động agent được định nghĩa sẵn, nhúng các bước cần hệ thống bên ngoài như tuân thủ/kiểm toán/triển khai ngay vào quy trình. Muốn ép đội ngũ viết spec, hãy chọn Kiro — vì không viết spec, Kiro sẽ không khởi động được (AWS Kiro official 2025.7; Kiro.dev docs 2026).

OpenAI Codex: AGENTS.md + Skills có thể kết hợp. Giai đoạn 2025-2026 đã đưa AGENTS.md lên vị trí trung tâm của hệ sinh thái. Skills là phần mở rộng quan trọng của nửa đầu 2026: các quy trình như “đọc file Excel”, “tạo SQL”, “chạy migration dữ liệu” được đóng gói sẵn, gọi ra như lắp ghép Lego. Lượng người dùng hoạt động hàng tuần của Codex đã vượt 5 triệu vào tháng 6/2026, trong đó 20% không phải là developer — đây là tín hiệu thường bị bỏ qua: việc vận hành theo chuẩn không còn là chuyện riêng của đội ngũ kỹ thuật, mà là việc của tất cả mọi người. Cả product, operation lẫn risk management đều đang viết AGENTS.md (thông báo OpenAI ngày 2/6/2026; đánh giá thebcms.com 2026, score 0.801).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic đặt tên cho tài liệu hướng dẫn dự án là CLAUDE.md (gia nhập chợ chính thức vào tháng 2/2026), .claude/rules/ (quy tắc phân tầng theo thư mục) và Skills (quy trình làm việc có thể chia sẻ). Claude Code là công cụ có mức độ hài lòng cao nhất từ trước đến nay trong nửa đầu 2026 — khảo sát JetBrains 2026.1 ghi nhận CSAT 91%, NPS 54, và hai khảo sát độc lập khác (Pragmatic Engineer 2026.2) cho kết quả nhất quán. Đây là điểm số cao nhất hiện tại trong cuộc đua công cụ lập trình AI (uvik.net 2026.5, 0.956 score, tổng hợp từ nguồn cấp một). Claude Code đã tăng từ con số 0 lên 2,5 tỷ USD doanh thu định kỳ hàng năm chỉ trong 9 tháng (theo vòng gọi vốn Series G của Anthropic, 2026.2), với 112.000 stars trên GitHub (kho Skills) — các nhà phát triển đã bỏ phiếu bằng hành động, cho thấy giá trị thực sự của cách tiếp cận theo chuẩn mực.

Alibaba Qoder: Động lực tuân thủ tại thị trường Trung Quốc. Ra mắt vào tháng 8/2025, nâng cấp lên phiên bản 1.0 vào ngày 15/5/2026, chính thức chuyển từ “AI IDE” thành “Autonomous Agent Development Workbench”. Spec-Driven Workflow của nó được giới thiệu cùng với Quest Mode (tác vụ đa tệp tự chủ), Expert Mode (nhóm chuyên gia xử lý song song) và RepoWiki (đồ thị tri thức kho lưu trữ). Ngày 28/5/2026 ra mắt Cloud Agents (môi trường chạy agent được quản lý hoàn toàn), ngày 21/7 ra mắt Qoder Security (năng lực bảo mật tuân thủ), cùng tháng đó phát hành bản Mobile (Android/iOS/HarmonyOS). Đến tháng 5/2026, người dùng toàn cầu đã vượt 5 triệu, và DingTalk CLI liệt kê nó là một trong những môi trường thực thi agent được hỗ trợ (Yahoo Finance 2025; Alibaba Cloud official 2026; Baidu Baike 2026.7).

Khuôn mẫu chung: Việc “chúng ta cộng tác với AI như thế nào” cần được viết thành tài liệu một cách tường minh, đặt trong repository, để tất cả mọi người và mọi tác nhân AI đều làm việc theo cùng một bộ quy chuẩn. Năm nền tảng có cách triển khai khác nhau (tên file/số giai đoạn/cơ chế hook), nhưng mục tiêu hoàn toàn giống nhau.

Vì sao điều này lại tập trung xảy ra vào nửa đầu năm 2026? Bởi vì rào cản năng lực AI đã được vượt qua — Claude Code với tác nhân tự chủ, Codex với đa tác nhân song song, Cursor với khả năng tái cấu trúc đa file, AI không còn là “công cụ gợi ý hoàn thiện code” nữa, mà là “đồng nghiệp”. Tài liệu onboarding bạn có thể đưa cho đồng nghiệp mới, thì cũng phải cho AI đọc được.

III. Vận hành theo quy chuẩn là năng lực tổ chức, không phải lựa chọn công cụ

Đây là điểm quan trọng nhất dành cho người ra quyết định. Vận hành theo quy chuẩn không phải là chọn công cụ, mà là định nghĩa “tổ chức của chúng ta cộng tác với AI như thế nào”. Bạn chọn GitHub Spec Kit hay Claude Code không quan trọng; điều quan trọng là bạn có viết quy chuẩn thành tài liệu, đưa vào repository, và để tất cả mọi người cùng AI làm việc theo nó hay không.

Nếu không có điều này, công cụ dù tốt đến đâu cũng chỉ giúp đội ngũ tạo ra nợ kỹ thuật nhanh hơn mà thôi.

Đặt vấn đề này trong bối cảnh triển khai quy mô lớn nửa đầu năm 2026, bằng chứng sẽ thuyết phục hơn. Trong báo cáo tổng kết FY26 công bố tháng 7/2026, Microsoft đã đưa hai trường hợp EY và Atos vào khuôn mẫu “Frontier Firm” — không phải vì mô hình mới, mà vì cả hai đều trả lời xong câu hỏi “dùng AI như thế nào” trước khi mở rộng:

EY: Chuẩn hóa đi trước, mở rộng để gặt hái. Trong giai đoạn 2024-2025, EY đã triển khai Microsoft 365 Copilot cho 150.000 nhân viên, tiết kiệm 2,5 triệu giờ làm việc, tương đương khoảng 250 triệu USD. Điều kiện tiên quyết là “khung quản trị AI được xây dựng trước”: EY dùng Power Platform, Copilot Studio, Azure, Foundry và Fabric để tạo một chuỗi công cụ thống nhất, đưa chuẩn mực/tuân thủ/kiểm toán vào cùng một nền tảng. Nhờ đó mới có kết quả 95% tăng tốc xử lý, 37% giảm chi phí vận hành tài chính, và giảm tới 90% quy trình thủ công. Phó chủ tịch EY phát biểu rất thẳng thắn tại AI Tour 2026: “Chúng tôi không triển khai AI trước rồi mới vá quản trị, mà xây quản trị trước rồi mới triển khai AI”.

Atos: Một mặt phẳng điều khiển thống nhất cho 19.000 agent. Atos là một trong những tổ chức đầu tiên trên thế giới triển khai Microsoft 365 E7 (Frontier Suite), đưa Copilot đến 56.000 nhân viên tại 54 quốc gia. Hiện tại họ đang vận hành song song 19.000 AI agent — từ IT nội bộ, các bộ phận kinh doanh cho đến dự án khách hàng, tất cả đều được xây dựng trên nền tảng Foundry và Copilot Studio. Chìa khóa thành công của Atos nằm ở “một mặt phẳng điều khiển duy nhất”: Entra (danh tính) + Defender (bảo mật) + Intune (thiết bị) + Purview (tuân thủ) + Agent 365 (quản trị agent) — năm thành phần được gắn kết chặt chẽ với nhau. Cách tiếp cận tích hợp này, khi áp dụng vào ngành tài chính, tương đương với việc kết hợp “đánh giá bảo mật cấp độ + đánh giá xuất dữ liệu xuyên biên giới + đăng ký thuật toán + kiểm toán + quản trị mô hình” — về bản chất là một kiến trúc quản trị, chứ không đơn thuần là một công cụ AI.

Nghịch lý thay đổi tổ chức của chính Microsoft. Trong báo cáo Work Trend Index 2026, Microsoft tự thừa nhận một điều: “Tốc độ thay đổi tổ chức đang tụt hậu so với tốc độ áp dụng của cá nhân.” Trong số 20.000 người dùng AI được khảo sát, 82% lãnh đạo có kế hoạch mở rộng lực lượng lao động bằng AI agent trong vòng 12–18 tháng, nhưng chỉ 24% đã triển khai ở cấp doanh nghiệp. 81% lãnh đạo dự đoán AI agent sẽ được tích hợp ở mức trung bình đến cao vào chiến lược AI — nhưng cũng chỉ 24% đã làm được điều đó. Điều này cho thấy đa số doanh nghiệp vẫn còn cách 12–18 tháng giữa “chuẩn bị” và “hoàn thành”. Khoảng cách này được lấp đầy bằng cách nào, quản trị theo chuẩn mực (governance) chính là trụ cột chính.

Nguồn: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, nguồn chính PDF); phân tích của Futurum Group 2026.1.26 (nguồn phụ).

Bài học một: Đầu tư vào quản trị là ROI cao.

Dữ liệu từ CodeRabbit cung cấp cơ sở rõ ràng để tính ROI: tỷ lệ lỗi phát sinh từ AI khoảng 1,7 lần, nhưng rủi ro bảo mật giảm 2,74 lần. Điều này có nghĩa là:

  • Ít phải làm lại hơn (trong lĩnh vực tài chính, một lần làm lại do kiểm tra tuân thủ có thể mất 2-4 tuần)
  • Ít sự cố an ninh hơn (một vụ rò rỉ dữ liệu kéo theo tiền phạt từ cơ quan quản lý và tổn hại danh tiếng)
  • Chi phí bảo trì thấp hơn (giảm 40% nợ kỹ thuật là con số phổ biến)

Viết một tài liệu chuẩn dự án như CLAUDE.md/AGENTS.md là hành động kỹ thuật có ROI cao nhất trong thời đại AI. Ví dụ từ EY cho thấy sự chuyển đổi trong thế giới thực — 150.000 nhân viên sử dụng Copilot, tiết kiệm 250 triệu USD. Lưu ý rằng EY đạt được điều này không phải vì “công cụ mạnh”, mà vì “các chuẩn mực đã giúp phát huy hết giá trị của công cụ”.

Bài học thứ hai: Đưa các chuẩn mực vào quy trình của tổ tổ chức, thay vì phụ thuộc vào cá nhân.

Nếu các chuẩn mực chỉ nằm trong đầu một kỹ sư giàu kinh nghiệm, thì khi người đó chuyển đi, mọi thứ sẽ mất. Chúng phải được lưu trữ ở:

  • Tài liệu trong kho mã (AGENTS.md / CLAUDE.md / constitution.md)
  • Cổng kiểm soát CI (tự động kiểm tra việc tuân thủ các chuẩn mực)
  • Cấu hình dùng chung cho cả nhóm (hệ thống Skills giúp toàn đội cùng sử dụng)

Để quy chuẩn trở thành tài sản của tổ chức, không phải kỹ năng cá nhân. Điều này đặc biệt quan trọng trong ngành tài chính — yêu cầu tuân thủ, quy tắc bảo mật, quy tắc nghiệp vụ của các bạn đều là tài sản cấp tổ chức, không phải “kinh nghiệm” của một kỹ sư nào đó. 19.000 agent của Atos có thể chạy tại 54 quốc gia, vì governance không phải là “một người nào đó hiểu”, mà là “hệ thống bắt buộc”.

Bài học thứ ba: Cổng kiểm soát quan trọng hơn tốc độ.

Năm giai đoạn kiểm soát của GitHub Spec Kit (constitution → specify → plan → tasks → implement), nguyên tắc “không viết code trước khi test thất bại” của Claude Code, hay việc Kiro “không khởi động được nếu chưa có spec” — tất cả đều đang làm cùng một việc: thêm một chiếc “phanh” giữa AI và sản phẩm cuối cùng. Mỗi bước đều có sản phẩm kiểm tra được (spec.md, plan.md, tasks.md), đều có thể bị từ chối hoặc chỉnh sửa trước khi code được sinh ra.

AI càng tự chủ, càng cần cổng kiểm soát. Hội đồng phê duyệt thay đổi (Change Advisory Board – Change Advisory Board (CAB)) trong ngành tài chính, quy trình đăng ký thuật toán, hay hoạt động đánh giá an ninh theo cấp độ (đẳng cấp bảo hộ) — về bản chất đều là thêm cổng kiểm soát trước khi đưa vào sản xuất. Code do AI tạo ra cũng cần cổng kiểm soát tương tự, chỉ khác về hình thức. 62% nhóm “tự tin phát hành mà không review” trong báo cáo 2026 của New Relic đang phải trả giá cho sự tự tin đó bằng tỷ lệ sự cố cao hơn (78%).

Ba giai đoạn triển khai quy chuẩn ngành tài chính Giai đoạn đầu tiên：Kiểm kê quy tắc 2-4 tuần｜Tốn thời gian nhất，ROI cao nhất Danh sách yêu cầu tuân thủ（Bảo vệ/ Xuất cảnh/ Đăng ký） Quy tắc bảo mật（Mật khẩu/ Mã hóa/ Nhật ký） Kiểm soát rủi ro/Giao dịch/Quy tắc tính phí Cổ giao diện/Phiên bản giới hạn Hợp đồng/Kiểm toán/Trách nhiệm Quy tắc sắp xếp Tài liệu cấu trúc Kho lưu trữ hạ cánh 1-2 tuần｜Kho lưu trữ tải CLAUDE.md / AGENTS.md constitution.md Làm việc chia sẻ Thiết kế quy trình Quy tắc phân lớp Quy tắc kho Tải tự động Cơ chế hóa Năng lực tổ chức Kiểm tra tự động Chia sẻ kỹ năng (Skills) Đánh giá định kỳ (Đánh giá quý) Đo lường (Tỷ lệ lỗi / tỷ lệ thành công) Đại lý quản trị (Agent 365 cấp 1) Tiêu chuẩn trở thành tài sản của tổ chức, Không phụ thuộc vào cá nhân

Giai đoạn đầu tiên tốn nhiều thời gian nhất, nhưng ROI cao nhất
Phần lớn các tổ chức tài chính có quy tắc phân tán trong tài liệu / email / bộ não, lần đầu tiên sắp xếp là đầu tư 3-8 tuần

Bốn. Ba giai đoạn triển khai thực tế trong nửa đầu 2026

Lấy ngành tài chính làm ví dụ cho lộ trình ba giai đoạn, các ngành chịu quản lý chặt chẽ khác có thể tham khảo. Thực tiễn triển khai của EY và Atos trong nửa đầu 2026 tương ứng với ba giai đoạn này.

Giai đoạn một: Rà soát quy tắc (2–4 tuần).

Đây là giai đoạn tốn thời gian nhất nhưng mang lại ROI cao nhất. Hãy tìm ra tất cả các quy tắc đang nằm rải rác ở khắp nơi:

  • Yêu cầu tuân thủ: Mức tối thiểu cho ngành tài chính = Đẳng cấp bảo vệ cấp 3 + Đánh giá xuất cảnh dữ liệu + Đăng ký thuật toán (thiếu một trong ba thì đừng triển khai AI), bên trên còn có các quy định về báo cáo giám sát, bảo vệ thông tin khách hàng, hạn chế luân chuyển dữ liệu xuyên biên giới, và xác định dữ liệu nào có thể cho AI truy cập
  • Quy tắc bảo mật: Quản lý mật khẩu, tiêu chuẩn mã hóa, xử lý trường dữ liệu nhạy cảm, yêu cầu về nhật ký hệ thống
  • Quy tắc nghiệp vụ: Ngưỡng kiểm soát rủi ro, điều kiện bồi thường, hạn mức giao dịch, logic tính phí
  • Ràng buộc kỹ thuật: Giao diện hệ thống cũ, quy ước đặt tên cơ sở dữ liệu, giới hạn phiên bản framework
  • Quản trị nhà cung cấp: Cách yêu cầu nhà cung cấp tuân thủ tiêu chuẩn của mình trong hợp đồng, cách kiểm toán việc sử dụng AI của nhà cung cấp

Tình huống điển hình: cách hệ thống hóa và quản trị quy tắc

Đây là tình huống mẫu: Một ngân hàng thương mại cổ phần trong giai đoạn rà soát phát hiện quy tắc nằm rải rác trong rất nhiều tài liệu Word, JIRA wiki, email cá nhân và bảng Excel — sau khi sắp xếp mới có được danh sách quy tắc có cấu trúc. Ví dụ, một tổ chức tài chính áp dụng cách làm của Atos, trực tiếp chia quy tắc theo năm nhóm “tuân thủ, bảo mật, nghiệp vụ, kỹ thuật, nhà cung cấp”, mỗi nhóm có một quy trình quản trị riêng, thống nhất kết nối vào mặt phẳng điều khiển Agent 365.

Đây không phải việc kỹ thuật, mà là việc tổ chức — anh phải kéo phòng tuân thủ, phòng an ninh, phòng nghiệp vụ ngồi lại với nhau, cùng viết ra những quy tắc mà mọi bên đều công nhận. Lần đầu làm việc này, một tổ chức tài chính thường mất 3–8 tuần — nhưng đó là tài sản tổ chức vĩnh viễn.

Giai đoạn hai: Đưa xuống kho lưu trữ (1–2 tuần)

Viết các quy tắc đã hệ thống hóa ở giai đoạn một thành tài liệu, đưa vào kho lưu trữ. Ví dụ, GitHub Spec Kit dùng constitution.md, Claude Code dùng CLAUDE.md, OpenAI Codex dùng AGENTS.md, Alibaba Qoder dùng Spec Workflow. Tên file khác nhau, nhưng mục tiêu giống nhau — để AI tải ngay khi mở kho lưu trữ.

Công cụ và nền tảng

  • GitHub Spec Kit: công cụ lập trình AI theo đặc tả của GitHub.
  • AWS Kiro: Agent IDE đặc tả của AWS.
  • OpenAI Codex: công cụ lập trình AI của OpenAI.
  • Claude Code: công cụ lập trình AI của Anthropic.
  • Alibaba Qoder: nền tảng AI IDE của Alibaba.
  • Cursor: trình soạn code AI hỗ trợ nhiều mô hình.
  • Copilot: trình soạn code AI của Microsoft/GitHub.
  • CodeRabbit: nền tảng review code AI.

Cấu trúc đề xuất (xu hướng chủ đạo nửa đầu 2026):

  • Tổng quan dự án: Hệ thống này dùng để làm gì, phục vụ ai
  • Nguyên tắc bất khả nhượng: Ranh giới đỏ về bảo mật, tuân thủ, và nghiệp vụ
  • Tech stack và ràng buộc: Dùng framework nào, database nào, chuẩn API ra sao
  • Quy chuẩn code: Quy ước đặt tên, cấu trúc thư mục, yêu cầu tối thiểu về độ phủ test (không bắt buộc áp dụng TDD — chỉ cần quy định rõ tỷ lệ bao phủ, các luồng bắt buộc phải test, và các luồng cấm test; TDD là lựa chọn tổ chức, không phải yêu cầu cứng từ quy chuẩn)
  • Quy tắc nghiệp vụ: Logic kiểm soát rủi ro, quy tắc giao dịch, quy tắc tính phí
  • Yêu cầu tuân thủ: Xếp hạng bảo mật cấp độ, luồng dữ liệu xuyên biên giới, báo cáo giám sát, thuật toán AI tạo sinh có cần đăng ký/khai báo hay không
  • Quy chuẩn sử dụng AI: Trường hợp nào được dùng AI, trường hợp nào bắt buộc con người kiểm duyệt, quy tắc đưa dữ liệu ra ngoài
  • Quản trị nhà cung cấp: Điều khoản hợp đồng, cơ chế kiểm toán, phân định trách nhiệm

Phụ lục: Khung CLAUDE.md cho ngành tài chính (khoảng 200 dòng, có thể fork về tùy chỉnh ngay)

Dưới đây là khung CLAUDE.md dành cho dự án nâng cấp hệ thống core banking của ngân hàng thương mại cổ phần, được sắp xếp theo thứ tự “Nguyên tắc bất khả nhượng → Yêu cầu tuân thủ → Quy chuẩn sử dụng AI → Quy tắc nghiệp vụ → Ràng buộc kỹ thuật”. Công ty bạn không cần bắt đầu từ con số 0 — chỉ cần điền các quy định cụ thể của mình vào những chỗ trống.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
# CLAUDE.md — <tên hệ thống> Quy chuẩn phối hợp AI

> Phạm vi áp dụng: <tên hệ thống> v<phiên bản>, mọi tác nhân AI (Claude Code / Cursor / Copilot / Codex)
> khi làm việc trên kho lưu trữ này đều phải tuân thủ quy chuẩn. Tài liệu này do <ủy ban quản trị> duy trì, đánh giá hàng quý.
> Cập nhật lần cuối: YYYY-MM-DD

## 1. Tổng quan dự án
- **Định vị nghiệp vụ**: tên hệ thống core / nhóm khách hàng phục vụ / loại giao dịch chính
- **Chuỗi quan trọng**: giao dịch → kiểm soát rủi ro → thanh toán bù trừ → đối chiếu → báo cáo theo quy định
- **Cửa sổ không khả dụng**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (cấm mọi thay đổi đi vào)
- **Phụ thuộc cốt lõi**: hệ thống <X> phía thượng nguồn, hệ thống <Y> phía hạ nguồn, nền tảng báo cáo theo quy định

## 2. Nguyên tắc không thể thương lượng (ranh giới đỏ — vi phạm = từ chối merge)

### 2.1 Đường đỏ bảo mật
- Mật khẩu, khóa, Token đều phải đi qua KMS (Dịch vụ quản lý khóa), **cấm hardcode**, **cấm in vào log**
- Các trường nhạy cảm của khách hàng (CMND/CCCD / số thẻ / CVV / số điện thoại) **bắt buộc mã hóa khi lưu trữ**, cấm lưu bản rõ vào database
- Trong log cấm xuất hiện: CMND/CCCD đầy đủ, số thẻ đầy đủ, mật khẩu rõ, tổ hợp tên khách hàng + số điện thoại
- Gọi API bên ngoài bắt buộc phải qua API gateway, cấm kết nối trực tiếp

### 2.2 Đường đỏ tuân thủ
- Code do AI sinh ra nếu liên quan đến truy cập dữ liệu khách hàng, phải ghi chú "truy cập dữ liệu: <trường>" trong mô tả PR
- Truyền dữ liệu xuyên biên giới bị cấm, **mọi dữ liệu xuất ra nước ngoài đều phải qua quy trình đánh giá truyền dữ liệu xuyên biên giới** (liên hệ phòng tuân thủ)
- Quyết định bằng thuật toán (tín dụng / định giá bảo hiểm / chống gian lận) phải giữ lối vào review thủ công của con người
- Thay đổi mô hình phải qua đăng ký thuật toán, số đăng ký phải được trích dẫn trong mô tả PR

### 2.3 Đường đỏ kinh doanh
- Thay đổi ngưỡng kiểm soát rủi ro cần trưởng phòng kiểm soát rủi ro + trưởng phòng nghiệp vụ ký kép
- Thao tác liên quan đến tiền của khách hàng phải có thiết kế idempotent + rollback khi thất bại
- Hạn mức giao dịch, biểu phí, tham số sản phẩm thay đổi qua nền tảng quản lý tham số, không hardcode trong code

## 3. Ngăn xếp công nghệ và ràng buộc
- **Ngôn ngữ**: Java 17 (core) / Kotlin (module mới) / SQL (database)
- **Framework**: Spring Boot 3.x + Spring Cloud Alibaba
- **Database**: OceanBase 4.x (chế độ tương thích MySQL), **cấm dùng khóa ngoại**
- **Chuẩn giao tiếp**: bên trong dùng gRPC; giao tiếp ra ngoài dùng OpenAPI 3.0; RESTful chỉ dành cho giao tiếp quản trị
- **Quy ước đặt tên**: class Java đặt PascalCase, method đặt camelCase, hằng số đặt UPPER_SNAKE; tên bảng `t_<miền nghiệp vụ>_<thực thể>`; chỉ mục `idx_<bảng>_<cột>_<thứ tự>`
- **Cấu trúc package**: `com.<công ty>.<miền nghiệp vụ>.<miền con>.<tầng>` (ví dụ `com.bank.pay.tx.core.service`)

## 4. Tiêu chuẩn mã
- **Độ phủ test tối thiểu**: chuỗi quan trọng ≥ 80%, lớp tiện ích ≥ 60%, code mới trong PR phải kèm test
- **Đường dẫn bắt buộc test**: mọi controller phải có integration test (bao gồm đường dẫn thất bại); mọi nhánh enum phải có unit test
- **Đường dẫn cấm**: cấm sửa thư mục `<module di sản>` — phải dựng lớp adapter trước
- **Quản lý phụ thuộc**: thêm phụ thuộc bên thứ ba phải qua quét SCA + phê duyệt bảo mật

## 5. Quy tắc kinh doanh (theo miền)
### 5.1 Giao dịch
- Hạn mức đơn lẻ: <số tiền>; hạn mức ngày: <số tiền>; vượt hạn phải phê duyệt thủ công
- Khung giờ giao dịch: <HH:MM> ~ <HH:MM>
- Phát hiện giao dịch trùng: trong <khung thời gian> cùng <trường> được coi là trùng lặp

### 5.2 Kiểm soát rủi ro
- Thứ tự ưu tiên khớp blacklist: blacklist nội bộ → danh sách do cơ quan quản lý phát hành → đóng băng tư pháp
- Ngưỡng đầu ra mô hình chống gian lận: <điểm>; vượt ngưỡng phải qua review thủ công lần hai

### 5.3 Tính phí
- Thay đổi biểu phí phải có số phiên bản + ngày hiệu lực
- Đơn hàng lịch sử tính theo biểu phí tại ngày hiệu lực, không truy ngược

## 6. Yêu cầu tuân thủ
- MLPS Cấp 3: <cơ quan đánh giá>, <ngày đánh giá tiếp theo>
- Đánh giá truyền dữ liệu xuyên biên giới: phạm vi áp dụng (chỉ module nghiệp vụ xuyên biên giới)
- Đăng ký thuật toán: phạm vi áp dụng (tín dụng / định giá bảo hiểm và các thuật toán quan trọng khác), số đăng ký `<số đăng ký>`
- Báo cáo theo quy định: bảng ánh xạ trường của CBIRC / Ngân hàng Nhân dân Trung Quốc tại `<đường dẫn>`

## 7. Tiêu chuẩn sử dụng AI
- **Tình huống được dùng AI**: CRUD mẫu, sinh unit test, bản thảo tài liệu, gợi ý tối ưu SQL
- **Tình huống bắt buộc con người review**: logic kiểm soát rủi ro, quy tắc tính phí, kiểm soát quyền, mã hóa/giải mã, dữ liệu xuyên biên giới
- **Tình huống cấm AI tự làm một mình**: hồ sơ phê duyệt Change Advisory Board (CAB) (Change Advisory Board), thực thi thay đổi production, ứng phó sự cố
- **Quy tắc xuất dữ liệu**: dữ liệu huấn luyện / prompt / log đầu ra đều không được xuất ra nước ngoài; ưu tiên bản triển khai nội địa hóa (<nhà cung cấp>)
- **Yêu cầu kiểm toán**: mọi code do AI sinh ra phải ghi nhận "hỗ trợ AI: <tên công cụ>" trong mô tả PR

## 8. Quản trị nhà cung cấp
- **Tiêu chí nhập cuộc nhà cung cấp**: phải cung cấp báo cáo SOC 2 / ISO 27001; mô hình AI phải kèm model card
- **Điều khoản hợp đồng**: quyền sở hữu dữ liệu, khả năng giải thích mô hình, điều khoản rời bỏ, quyền kiểm toán
- **Cơ chế kiểm toán**: kiểm toán việc sử dụng AI của nhà cung cấp hàng quý; nhà cung cấp rủi ro cao kiểm toán hàng tháng

## 9. Quản trị và cập nhật
- **Chủ sở hữu**: <ủy ban quản trị> (tuân thủ + bảo mật + kiến trúc + nghiệp vụ)
- **Tần suất cập nhật**: đánh giá hàng quý; thay đổi khẩn cấp đi kênh nhanh (ký kép + công bố 24h)
- **Nhật ký thay đổi**: xem `CLAUDE_CHANGELOG.md`
- **Xử lý vi phạm**: vi phạm lần 1 = cảnh cáo + đào tạo bắt buộc; vi phạm lần 2 = đình chỉ dùng công cụ AI; lần 3 = thu hồi quyền

Bộ khung này không phải là “đáp án chuẩn”, mà là “mẫu điền thông tin”. Mỗi ô trống điền gì quan trọng hơn nhiều so với viết dài bao nhiêu — những chỗ trống phơi bày đúng phần mà công ty bạn “chưa nghĩ thấu đáo”.

Tình huống điển hình: CLAUDE.md của một ngân hàng cổ phần có quy định riêng về xử lý mật khẩu — mã do AI sinh ra nếu liên quan đến mật khẩu bắt buộc phải gọi internal key management API, nghiêm cấm hardcode. Các quy tắc kiểu này chiếm tỷ lệ rất cao trong các lý do bị trả về khi kiểm tra tuân thủ.

Một trường quan trọng mới trong H1 2026 là Skills/định nghĩa quy trình làm việc — không chỉ là tài liệu, mà là chuỗi công cụ mà AI có thể gọi. Hệ thống Skills của Claude Code (gia nhập chợ chính thức của Anthropic vào tháng 2/2026, 112.000 stars trên GitHub) biến các thao tác như “đọc file Excel”, “sinh SQL”, “chạy data migration” thành các quy trình làm việc có thể chia sẻ. Đây là bước tiến hóa then chốt của chuẩn hóa trong H1 2026: chuẩn hóa không chỉ là ràng buộc, mà là quy trình làm việc có thể thực thi.

Giai đoạn ba: Thể chế hóa (liên tục).

Viết规范 xong không phải là kết thúc, mà mới là khởi đầu. Bạn phải biến nó thành một phần quy trình vận hành của tổ chức:

  • Cổng CI (CI Gate): Tự động kiểm tra mã nguồn có tuân thủ规范 hay không (ví dụ: phát hiện mật khẩu bị hardcode, trường nhạy cảm chưa mã hóa)
  • Cấu hình dùng chung cho cả đội: Dùng hệ thống Skills để cả team dùng chung một bộ规范
  • Cơ chế cập nhật định kỳ: Quy tắc thay đổi thì规范 cũng phải thay đổi theo (review theo quý)
  • Đo lường và phản hồi: Theo dõi tỷ lệ lỗi của code do AI sinh ra, tỷ lệ vượt qua kiểm tra tuân thủ, tỷ lệ làm lại
  • Quản trị agent: Mở rộng quản trị từ con người sang AI agent — điều Atos đang làm trên Agent 365 chính là đưa việc này từ cấp “cá nhân” lên cấp “hệ thống”

EY và Atos trong H1 2026 đều coi giai đoạn ba là “năng lực tổ chức”. Khoản tiết kiệm 2,5 triệu giờ của EY đến từ việc làm đúng giai đoạn một và giai đoạn ba — giai đoạn hai chỉ đơn thuần là dịch các quy tắc thành tài liệu AI có thể đọc được.

Năm. Biến thể ngành siêu quản lý: Ba cách nhúng tuân thủ vào kỹ thuật

Với các ngành quản lý chặt như tài chính, viễn thông, y tế, việc áp dụng规范-driven khó hơn ngành thông thường một bậc — tuân thủ không phải thứ gắn bên ngoài quy trình, mà phải được nhúng ngay trong code. Ba cách dưới đây là các phương thức nhúng tuân thủ đã được kiểm chứng trong H1 2026, CIO/Giám đốc chuyển đổi số có thể tham khảo trực tiếp khi thiết kế tổ chức.

5.1 Nhúng đại diện tuân thủ vào trong stream team: Để tuân thủ “hiện diện” thay vì “phê duyệt”

Cách làm truyền thống: team nghiệp vụ viết code, team tuân thủ rà soát sau — khi rà soát phát hiện vấn đề thì code đã lên production nửa tháng, chi phí làm lại mất 2-4 tuần. Bản chất vấn đề là tuân thủ nằm ở cuối quy trình.

Cách làm mới: nhúng đại diện tuân thủ vào từng stream team (stream-aligned team), với mô hình báo cáo hai tuyến: “trực thuộc phòng tuân thủ, nhưng làm việc theo chỉ đạo của team nghiệp vụ”. Thiết kế cụ thể:

  • Biên chế nhân sự: cứ 6-8 stream team bố trí 1 đại diện tuân thủ, trực thuộc phòng tuân thủ, nhưng chỗ ngồi làm việc trong team nghiệp vụ — không phải kiểu “biệt phái” đi công tác
  • KPI theo tuyến chỉ đạo: 50% trọng số KPI của đại diện tuân thủ gắn với “tỷ lệ lỗi tuân thủ” và “tỷ lệ vượt qua review ngay lần đầu” của team nghiệp vụ, không chỉ đơn thuần nhìn vào “độ phủ kiểm toán” của phòng tuân thủ
  • Tham gia từ sớm: đại diện tuân thủ tham dự daily stand-up (mỗi tuần 1 lần là đủ), tham gia PR review, và code do AI sinh ra bắt buộc phải được đại diện tuân thủ duyệt trước khi merge — không phải sau khi merge mới phát hiện rồi xử lý bổ sung
  • Hỗ trợ bằng công cụ: đại diện tuân thủ dùng Skills gọi checklist tuân thủ để kiểm tra, thay vì đối chiếu thủ công từng dòng

Tình huống điển hình: Một ngân hàng cổ phần toàn quốc tại Trung Quốc trong nửa đầu năm 2026 đã thí điểm bố trí đại diện tuân thủ vào 3 đội ngũ phát triển (stream team), giúp tỷ lệ mã AI bị trả về vì vi phạm tuân thủ giảm từ 35% xuống còn 8% — điểm mấu chốt không phải là tuân thủ “giám sát chặt hơn”, mà là tuân thủ “nhìn thấy sớm hơn”. Yếu tố quyết định của cách làm này là chỉ tiêu chấm dứt (dotted-line KPI) của đại diện tuân thủ phải được gắn với mục tiêu kinh doanh — nếu KPI của họ vẫn chỉ do bộ phận tuân thủ giao, thì việc nhúng này coi như thất bại.

5.2 Biến bộ phận tuân thủ thành enabling team: chuyển ràng buộc thành điều kiện thuận lợi

Cách làm truyền thống: bộ phận tuân thủ đóng vai “người gác cổng”, còn đội ngũ kinh doanh xem tuân thủ là “kẻ gây rắc rối”. Hai bên chơi trò tổng bằng không (zero-sum).

Cách làm mới: bộ phận tuân thủ được tái cấu trúc theo mô hình enabling team trong Team Topologies — không trực tiếp viết code, không trực tiếp duyệt pull request, mà cung cấp ba thứ để đội ngũ kinh doanh có thể “tự phục vụ tuân thủ”:

  1. Kiểm tra tuân thủ trong pipeline CI: Các điểm tuân thủ tần suất cao như hardcode mật khẩu, lưu trữ trường nhạy cảm dưới dạng plaintext, truyền dữ liệu xuyên biên giới, và các điểm quyết định thuật toán — tất cả được đưa thành cổng kiểm soát bắt buộc trong GitHub Actions / GitLab CI. Khi team nghiệp vụ tạo PR, quy trình tự động kiểm tra và fail ngay nếu không tuân thủ — không cần nhân sự tuân thủ chạy kiểm tra thủ công từng lần.

  2. Biến yêu cầu pháp lý thành affordance (ràng buộc phản ứng theo ngữ cảnh): Ví dụ, khi dev xây dựng tính năng liên quan đến dữ liệu khách hàng, plugin IDE hiện gợi ý “trường này nên gọi KMS”; khi ghi log, hệ thống tự động phát hiện thông tin nhạy cảm và cảnh báo. Mục tiêu là biến tuân thủ thành “hành động tự nhiên trong lúc code”, không phải “đến lúc release mới bị báo là vi phạm điều gì”.

  3. Thư viện Skills dùng chung + đào tạo tuân thủ: Đội tuân thủ duy trì một bộ “Compliance Skills” — nhân viên mới hoặc người chuyển team chỉ cần gọi ra dùng ngay. Cách này chuyển kiến thức tuân thủ từ “tài liệu” thành “công cụ thực thi được”.

Tình huống điển hình: Một ngân hàng thương mại khu vực triển khai cổng kiểm tra tuân thủ CI + cảnh báo tuân thủ trên IDE trong H1 2026, giảm thời gian trung bình cho mỗi lần rà soát tuân thủ mã AI từ 45 phút xuống còn 8 phút. Điểm cốt lõi không phải là “quy trình rà soát nhanh hơn”, mà là mã AI ngay từ khi sinh ra đã “không phạm lỗi”.

5.3 Tuân thủ hai tốc độ: phân tầng theo nhịp độ kinh doanh

Chi tiết cuối cùng: tuân thủ không nên “áp dụng một kiểu cho tất cả”. Hãy chia quy tắc thành hai cấp độ theo mức độ rủi ro:

  • Quy tắc rủi ro cao (liên quan đến tiền của khách hàng / quyết định thuật toán / dữ liệu xuyên biên giới / đường ranh đỏ an ninh mạng) áp dụng cổng kiểm soát nghiêm ngặt: phải có đánh giá thủ công + xác nhận lần hai bằng AI + lưu hồ sơ tại Change Advisory Board (Change Advisory Board (CAB))
  • Quy tắc rủi ro thấp (mẫu CRUD / code tiện ích / tạo tài liệu) áp dụng cổng tự phục vụ: chỉ cần CI tự động kiểm tra, không cần đánh giá thủ công

Về bản chất, mặt phẳng điều khiển của Agent 365 của Atos chính là sự phân tầng này — các cấp độ agent khác nhau được gắn với các yêu cầu quản trị khác nhau. Phân tầng quy tắc tuân thủ theo rủi ro giúp đội ngũ kinh doanh cảm thấy “tuân thủ không phải là thứ chặn mình ở mọi nơi”.

Kết luận tổng hợp cho ba điều này: nhúng tuân thủ không phải là thêm một quy trình, mà là thiết kế lại cấu trúc và động lực của đội ngũ. Nếu bộ phận tuân thủ của bạn vẫn đang ở chế độ “đánh giá sau sự việc”, thì việc triển khai quy trình theo chuẩn sẽ mắc kẹt ở bước khó nhất — “thể chế hóa” — bộ phận tuân thủ cần chuyển đổi trước, thì quy trình theo chuẩn của đội ngũ kỹ thuật mới chạy thông suốt được.

VI. Những câu hỏi bạn có thể thắc mắc

“Chúng tôi đã có coding standards rồi, khác gì với cái này?”

Coding standards quản lý “viết code như thế nào”, còn quy trình theo chuẩn (spec-driven) quản lý “cộng tác với AI như thế nào”. Coding standards không bao gồm: quy tắc nghiệp vụ, yêu cầu tuân thủ, chính sách sử dụng AI. Quy trình theo chuẩn là việc hiển thị hóa “toàn bộ quy trình cộng tác giữa người và AI”, không phải là một style guide cho code.

“Viết spec có làm chậm tốc độ phát triển không?”

Về ngắn hạn thì có, nhưng về dài hạn thì không. Số liệu từ CodeRabbit đã cho câu trả lời rõ ràng: code do AI tạo ra mà không có ràng buộc có nguy cơ lỗi cao gấp khoảng 1,7 lần và lỗ hổng bảo mật cao gấp 2,74 lần. Trong ngành tài chính, một lần làm lại do kiểm tra tuân thủ tốn 2–4 tuần — chỉ cần tránh được một lần làm lại là đủ để bạn dành cả tháng để viết spec. Khoản tiết kiệm 250 triệu USD của EY chính là bằng chứng thực tế cho việc biến điều này thành năng lực tổ chức.

“Đội của chúng tôi không ai biết viết spec thì phải làm sao?”

Không cần bắt đầu từ con số không. GitHub Spec Kit, Claude Code Superpowers, AWS Kiro đều có sẵn template. Bạn chỉ cần điền vào đó những quy tắc riêng của tổ chức mình — phần lớn là quy tắc tuân thủ và bảo mật, mà bộ phận compliance và bộ phận an ninh mạng đã viết sẵn từ lâu rồi, chỉ là chưa được đặt vào nơi mà AI có thể đọc được mà thôi.

“Có quá nhiều công cụ AI, chọn cái nào đây?”

Không quan trọng. Cứ chọn cái mà anh chị đang dùng. Chuẩn hoá theo nguyên tắc, không gắn với công cụ — CLAUDE.md dùng được trong Claude Code, Cursor, Codex; AGENTS.md chạy được trong hệ sinh thái OpenAI; constitution.md thì không phụ thuộc vào model nào. Điều cốt lõi là viết ra chuẩn, không phải đổi công cụ. EY triển khai trong hệ sinh thái Microsoft, Atos cũng triển khai trong hệ sinh thái Microsoft — sự khác biệt về lựa chọn công cụ chỉ là bề nổi, còn sự thống nhất trong kiến trúc quản trị mới là phần cốt lõi.

“Tháng 8/2026, EU AI Act chính thức có hiệu lực toàn diện — điều đó có ảnh hưởng đến chúng ta không?”

Có. EU AI Act bước vào giai đoạn thực thi đầy đủ từ ngày 2/8/2026, với các yêu cầu tuân thủ bắt buộc đối với hệ thống AI rủi ro cao (bao gồm tín dụng ngân hàng, định phí bảo hiểm, tuyển dụng nhân sự, hạ tầng trọng yếu) như: quản lý rủi ro (Art. 9), quản trị dữ liệu (Art. 10), tính minh bạch tài liệu (Art. 11-13), giám sát của con người (Art. 14), độ chính xác/độ tin cậy (Art. 15). Mức phạt vi phạm lên đến 35 triệu EUR hoặc 7% tổng doanh thu toàn cầu. Đối với các doanh nghiệp Trung Quốc xuất khẩu ra nước ngoài, thị trường EU là bài toán bắt buộc phải trả lời; với doanh nghiệp nội địa, khung EU AI Act cũng là tiêu chuẩn được tham chiếu nhiều nhất trên toàn cầu — bạn có thể không trực tiếp thuộc diện điều chỉnh, nhưng khó lòng né tránh các tác động lan truyền của nó qua chuỗi nhà cung cấp, đối tác và hoạt động kinh doanh xuyên biên giới (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

Khía cạnhEU AI ActQuy định quản lý dịch vụ AI tạo sinh của Trung Quốc
Vị thế pháp lýQuy định ngang (áp dụng cho mọi hệ thống AI)Quy định dọc (tập trung vào dịch vụ AI tạo sinh)
Phân loại rủi ro4 cấp (không thể chấp nhận / cao / hạn chế / tối thiểu)2 cấp (liên quan đến an ninh dư luận / thương mại thông thường)
Thời điểm giám sátTiền kiểm (đăng ký ngay từ giai đoạn phát triển)Hậu kiểm (đăng ký sau khi ra mắt + đăng ký thuật toán)
Minh bạchCao (yêu cầu công bố tóm tắt nguồn dữ liệu huấn luyện, model card)Trung bình (yêu cầu tuân thủ về ngữ liệu nhưng không bắt buộc công bố nguồn)
Trần mức phạt7% doanh thu toàn cầu hoặc 35 triệu EURĐình chỉ dịch vụ / phạt tiền (thường là bội số của khoản thu bất hợp pháp)
Phạm vi áp dụngMọi doanh nghiệp đạt ngưỡng doanh thu toàn cầuMọi chủ thể cung cấp dịch vụ trong lãnh thổ Trung Quốc

Trên thực tế, tại Việt Nam, hệ thống AI của các tổ chức tài chính thường đồng thời chịu sự ràng buộc của ba lớp quy định — Nghị định 13/2023/NĐ-CP (lớp bảo vệ dữ liệu cá nhân) + Luật An toàn thông tin mạng 2015 + Nghị định 85/2016 (lớp bảo vệ an ninh mạng cấp độ) + Luật An ninh mạng 2018 (lớp an ninh quốc gia, bao gồm cả đăng ký xuyên biên giới với Bộ Công an — MPS). Điều này có nghĩa là khi triển khai SDD tại Việt Nam, không thể sao chép nguyên khuôn khổ EU AI Act, mà phải đưa cả ba tuyến “tuân thủ dữ liệu cá nhân + bảo vệ an ninh mạng cấp độ + đăng ký xuyên biên giới MPS” vào file CLAUDE.md.

Đối với doanh nghiệp ra nước ngoài: bộ tứ “quản lý rủi ro + quản trị dữ liệu + minh bạch tài liệu + giám sát con người” của EU AI Act cũng chính là hướng mà cơ quan quản lý trong nước đang dần tiến tới — phản hồi từ một số đợt đăng ký AI tạo sinh của Cục An ninh mạng năm 2025 đã rõ ràng tham chiếu mức độ chi tiết của EU. Hôm nay viết quy chuẩn tương thích EU AI Act, 3 năm tới rất có thể cũng tương thích với xu hướng thắt chặt trong nước (thông báo đăng ký của Cục An ninh mạng 2025–2026; eu-ai-act compliance 2026.6).

Bảy. Hàm ý cho người ra quyết định

Hàm ý một: Viết một file quy chuẩn dự án CLAUDE.md/AGENTS.md là hành động kỹ thuật có ROI cao nhất trong kỷ nguyên AI.

Chi phí đầu tư là 3-8 tuần để hệ thống hóa tài liệu + 1-2 tuần để soạn thảo. Lợi ích nhận được: giới hạn rủi ro lỗi giảm khoảng 1,7 lần, lỗ hổng bảo mật giảm 2,74 lần, tỷ lệ làm lại giảm hơn 40%. Trong ngành tài chính, chỉ cần tiết kiệm được một lần làm lại do kiểm tra tuân thủ (2-4 tuần) là đã đủ bù đắp chi phí này. EY triển khai Copilot cho 150.000 nhân viên tiết kiệm được 250 triệu USD, nhưng điều kiện tiên quyết là phải có quy chuẩn rõ ràng.

Bài học thứ hai: Chuẩn hóa theo quy trình là năng lực tổ chức, không phải lựa chọn công cụ.

Bạn chọn GitHub Spec Kit hay Claude Code không quan trọng — điều quan trọng là bạn đã định nghĩa được “tổ chức của chúng tôi cộng tác với AI như thế nào”. Nếu không có điều đó, dù công cụ tốt đến đâu cũng chỉ giúp đội ngũ tạo ra nhiều nợ kỹ thuật nhanh hơn mà thôi.

Bài học thứ ba: Đưa quy chuẩn vào quy trình tổ chức, không phụ thuộc vào cá nhân.

Nếu quy chuẩn chỉ tồn tại trong đầu một kỹ sư kỳ cựu nào đó, thì khi nhân sự biến động là mất. Bắt buộc phải lưu trữ vào tài liệu kho lưu trữ, cổng kiểm soát CI, cấu hình dùng chung của nhóm, và nền tảng quản trị agent. Biến quy chuẩn thành tài sản tổ chức, không phải kỹ năng cá nhân. 19.000 agent của Atos vận hành được tại 54 quốc gia, vì việc quản trị không phải là “một người nào đó hiểu”, mà là “hệ thống bắt buộc”.

Bài học thứ tư: Kiểm soát cổng (gate) quan trọng hơn tốc độ.

Năm cổng kiểm soát giai đoạn của GitHub Spec Kit, nguyên tắc “không viết code trước khi test thất bại” của Claude Code Superpowers, hay việc Kiro “không khởi động được nếu chưa có spec” — tất cả đều đang thêm một chiếc “phanh” giữa AI và sản phẩm cuối cùng. Năng lực AI càng mạnh, governance càng phải đi trước. Tỷ lệ sự cố 78% trong báo cáo New Relic 2026 là cái giá phải trả cho việc 62% đội “phát hành mà không review”. CIO ngành tài chính hiểu rõ điều này nhất: Change Advisory Board (Change Advisory Board (CAB)), quy trình đăng ký thuật toán, đánh giá bảo vệ an ninh mạng cấp độ (MLPS) — tất cả đều là cổng kiểm soát trước khi đưa vào production. Code AI cũng cần cổng kiểm soát tương tự, và phải đặt lên phía trước hơn nữa.

Tự kiểm tra ngược (đừng tô hồng khi trả lời): Code AI do đội bạn sinh ra có hay bị trả lại ở khâu kiểm tra tuân thủ không? Sự cố gần nhất do code AI gây ra là gì? Nếu hỏi người phụ trách kỹ thuật “tổ chức mình cộng tác với AI như thế nào”, anh ta có đưa ra được một văn bản không? Ba câu hỏi này câu nào không trả lời được, nghĩa là quy trình chuẩn định hướng vẫn chưa được áp dụng — viết chuẩn trước, rồi hãy mua công cụ.

Ba câu hỏi coaching cho người ra quyết định

Cuối cùng để lại ba câu hỏi — không phải checklist, mà là những câu bạn và đội ngũ có thể dùng ngay khi thảo luận:

  1. “Nếu ngày mai tất cả các công cụ AI ngừng hoạt động, chất lượng code của team bạn sẽ giảm bao nhiêu?” — Câu hỏi này phơi bày giá trị thực sự của việc chuẩn hóa quy trình: nếu câu trả lời là “giảm đáng kể”, nghĩa là quy trình của bạn vẫn chưa được hệ thống hóa; nếu câu trả lời là “gần như không đổi”, thì việc vận hành theo chuẩn đã thực sự đi vào guồng.
  2. “Trong dự án chuẩn hóa quy trình của bạn, bộ phận tuân thủ đóng vai trò ‘người gác cổng’ hay ‘người hỗ trợ’?” — Nếu là “người gác cổng”, tốc độ triển khai của bạn sẽ bị nghẽn ở khâu phê duyệt; nếu là “người hỗ trợ”, bạn đã đi đúng hướng theo lộ trình ở mục 5.2.
  3. “Sau 12–18 tháng nữa, quy mô team của bạn sẽ thay đổi như thế nào?” — Theo báo cáo WTI 2026 của Microsoft, 82% nhà lãnh đạo sẽ dùng AI agent để “mở rộng” lực lượng lao động. Nếu câu trả lời của bạn là “không đổi”, thì hoặc là doanh nghiệp bạn không tăng trưởng, hoặc là cách tổ chức của bạn chưa theo kịp lợi ích mà chuẩn hóa quy trình mang lại.

Ba câu hỏi này không có đáp án chuẩn. Nhưng hướng của câu trả lời quan trọng hơn bản thân câu trả lời.

Bước tiếp theo

Đây là bài thứ sáu trong chuỗi “Chuyển đổi kỹ thuật phần mềm trong kỷ nguyên AI”. Từ Conway (tổ chức quyết định kiến trúc) đến Team Topologies (cách thiết kế tổ chức), rồi đến sự dịch chuyển điểm nghẽn (nghẽn ở khâu kiểm thử chứ không phải viết code), hôm nay chúng ta nói về việc vận hành theo chuẩn (dùng tài liệu để ràng buộc hành vi của AI).

Bài tiếp theo (bài thứ bảy), chúng ta sẽ xem xét hạ tầng nền tảng đỡ mọi thứ phía sau — giao thức MCP (Model Context Protocol): vì sao giao thức mã nguồn mở của Anthropic được gọi là “USB-C của AI”, vì sao OpenAI, Google, Microsoft đều nối gót, và nó giúp khả năng tương tác giữa nhiều công cụ, nhiều agent trở nên khả thi như thế nào.

Muốn áp dụng bộ tiêu chí này vào công ty của bạn?

Khi chuẩn định hướng đi vào doanh nghiệp, những vấn đề cụ thể thường cần giải quyết là: làm sao để các quy tắc cốt lõi kết tinh thành CLAUDE.md / AGENTS.md, code hiện có bổ sung chuẩn ra sao, nhúng tuân thủ như thế nào, và thí điểm nên dùng chỉ số gì để nghiệm thu.

Hiện có ba hình thức hợp tác:

  • Đào tạo nội bộ doanh nghiệp: kết hợp với dự án thực tế của công ty bạn, hoàn thiện việc soạn thảo tài liệu chuẩn, thiết kế CI gate, lộ trình nhúng tuân thủ và dựng cơ chế quản trị.
  • Tư vấn chuyên sâu: tập trung vào một quyết định rõ ràng, ví dụ “công ty chúng tôi có nên viết CLAUDE.md / AGENTS.md trước không”, hoặc ưu tiên xử lý tuân thủ cho code hiện có.
  • Chia sẻ cho ban lãnh đạo và diễn thuyết ngành: xoay quanh công cụ lập trình AI, chuẩn định hướng, quản trị tổ chức và các Frontier Firms.

慢慢 học AI 001: AI thời đại và sự thay đổi trong kỹ thuật phần mềm

“AI thời đại và sự thay đổi trong kỹ thuật phần mềm” là một loạt bài viết dành cho các nhà lãnh đạo công nghệ và số hóa trong các ngành điện信, tài chính, sản xuất và thương mại điện tử. Loạt bài này sẽ tập trung vào các công cụ lập trình AI, các quy định và tiêu chuẩn, cũng như các vấn đề tổ chức và quản lý trong quy trình giao hàng phần mềm.

Loạt bài này sẽ tiếp tục theo dõi các bài báo học thuật, tài liệu của các công ty và các báo cáo ngành, và thư viện tài liệu nghiên cứu đã tích lũy được hơn 200 bài. Chúng tôi sẽ cố gắng phân biệt các thực tế đã được xác minh, các tuyên bố của các công ty, các quan sát của ngành và các suy đoán của tác giả.

Tôi có hơn 8 năm kinh nghiệm trong lĩnh vực tư vấn và phân tích kinh doanh cho các doanh nghiệp lớn, và đã từng làm việc tại IBM, tham gia các dự án liên quan đến điện tín, tài chính, bảo hiểm và sản xuất. Sau đó, tôi tiếp tục làm việc trong các sản phẩm của các nhà mạng, các sản phẩm internet và phát triển ứng dụng AI, và đã tham gia vào việc phân tích nhu cầu, thiết kế sản phẩm và triển khai trong các nhóm.

Liên hệ

Nếu bạn muốn hợp tác hoặc muốn biết thêm thông tin, vui lòng liên hệ với chúng tôi qua địa chỉ coach@iaiuse.com.

Đọc thêm

《Phương pháp luận v1.0: Thấy được bảng hiệu》(慢慢 học AI 187), là một bài viết hệ thống giới thiệu 7 bước khung cho quá trình chuyển đổi AI của doanh nghiệp.

Loạt bài này đưa ra các nhận định về định hướng chuẩn mực, quản trị tổ chức và kỹ thuật dựa trên thực tiễn triển khai, kết hợp với nghiên cứu công khai và tình huống ngành để đối chiếu chéo. Mọi nội dung liên quan đến dự án cụ thể đều đã được ẩn danh hóa; một số tình huống ngành mang tính suy diễn từ các vấn đề điển hình, căn cứ tham khảo được nêu ở cuối bài.

Kênh này thực chất do một nhóm nhỏ vận hành — gồm tôi và 1–2 cộng sự hợp tác lâu dài, mỗi người phụ trách một mảng: nghiên cứu công cụ lập trình AI, tổng hợp tình huống quản trị tổ chức, và đối thoại huấn luyện. Phần lớn các dự án mà chúng tôi nhắc đến trong bài là do cả nhóm cùng triển khai. Ranh giới tuân thủ của khách hàng và tên cá nhân vẫn sẽ không được nêu cụ thể, giữ ẩn danh để dành không gian hợp tác cho đồng nghiệp trong tương lai.

Nguồn tham khảo (đã kiểm chứng, phân loại mức độ bằng chứng theo từng mục)

  • CodeRabbit (2025.12). State of AI vs Human Code Generation Report. Mã do AI tạo ra có số vấn đề gấp 1,7 lần mã do con người viết (10,83 so với 6,45 vấn đề/PR), logic/độ chính xác cao gấp 1,75 lần, chất lượng mã kém hơn 1,64 lần, bảo mật kém hơn 1,57 lần, xử lý mật khẩu kém hơn 1,88 lần, XSS cao gấp 2,74 lần. Mức độ bằng chứng: Cấp 1. Nguồn: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263

  • The Register (2025.12.17). Đưa tin toàn văn báo cáo CodeRabbit: phân tích 470 PR mã nguồn mở, PR có sự tham gia của AI chứa 10,83 vấn đề so với 6,45 vấn đề ở PR do con người viết hoàn toàn. Mức độ bằng chứng: Cấp 2. Nguồn: URL như trên

  • CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap” — 2026 là năm bản lề chuyển từ “tốc độ sinh mã” sang “chất lượng mã và quản trị”. Cấp độ bằng chứng: cấp 2. Nguồn: https://tfir.io/ai-code-quality-2026-guardrails

  • New Relic (2026). The 2026 State of AI Coding Report. 78% đội ngũ ghi nhận nhiều sự cố hơn sau khi đưa mã AI lên môi trường production; 62% lãnh đạo kỹ thuật thừa nhận đội ngũ của họ “tự tin phát hành mã AI mà không review”; 96% cho rằng observability là điều bắt buộc. Cấp độ bằng chứng: cấp 1 (báo cáo từ nhà cung cấp). Nguồn: https://newrelic.com/resources/report/2026-state-of-ai-coding

Báo cáo Thường niên Chỉ số Xu hướng Công việc 2026 của Microsoft (2026 Work Trend Index Annual Report). Khảo sát 20.000 nhân viên tri thức tại 10 quốc gia; 82% lãnh đạo dự định mở rộng lực lượng lao động bằng AI agent trong vòng 12–18 tháng tới; 81% dự kiến tích hợp AI agent ở mức trung bình hoặc đáng kể; 24% đã triển khai ở cấp doanh nghiệp; 49% cho biết Copilot hỗ trợ công việc nhận thức qua hội thoại; 58% người dùng AI thực hiện được “những việc mà một năm trước họ không thể làm”, và ở nhóm Frontier Professionals con số này tăng lên 80%. Cấp độ bằng chứng: Cấp 1. Nguồn: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf

  • Microsoft FY26 nhìn lại: từ thử nghiệm AI đến chuyển đổi ở biên giới công nghệ (28.07.2026). EY đã triển khai Microsoft 365 Copilot cho 150.000 nhân viên, tiết kiệm 2,5 triệu giờ làm việc và khoảng 250 triệu USD; sau đó mở rộng lên 400.000 nhân viên trên toàn cầu với tốc độ xử lý công việc được đẩy nhanh hơn 95%, chi phí vận hành tài chính giảm 37%, và khối lượng công việc thủ công giảm đến 90%. Atos triển khai Copilot cho 56.000 nhân viên tại 56 quốc gia cùng với 19.000 AI agent, thống nhất trên một mặt phẳng kiểm soát duy nhất về định danh, bảo mật, tuân thủ và quản trị hệ thống. Cấp độ bằng chứng: Cấp 1 — đánh giá chính thức từ Microsoft trong bài tổng kết năm tài chính 2026 của hãng này. Nguồn tham khảo: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Hợp tác chiến lược giữa Atos Group và Microsoft (09/06/2026). Atos triển khai Microsoft 365 E7 (Frontier Suite) cho 56.000 nhân viên tại 56 quốc gia, kèm 19.000 AI agent; hợp nhất mặt phẳng điều khiển Entra/Defender/Intune/Purview/Agent 365. Cấp độ bằng chứng: Cấp 1 (thông cáo báo chí chung từ hai bên). Nguồn: 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 (mã nguồn mở 9.2025, phát triển nửa đầu 2026). Quy trình 5 giai đoạn có kiểm soát /speckit.constitution → /specify → /plan → /tasks → /implement, kèm /clarify /analyze; không phụ thuộc vào mô hình (đều tương thích với Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code). Cấp độ bằng chứng: Cấp 1. Nguồn: https://github.com/github/spec-kit

  • AWS Kiro (ra mắt 7.2025, phát triển nửa đầu 2026). Quy trình làm việc ba giai đoạn: yêu cầu → thiết kế → tác vụ; spec kích hoạt các hành động đại lý đã định nghĩa trước; không viết spec thì không thể khởi động. Cấp độ bằng chứng: Cấp 1. Nguồn: https://kiro.dev/

  • OpenAI Codex + AGENTS.md + Skills (2025-2026). Codex 2026.6 đạt hơn 5 triệu người dùng hoạt động hàng tuần, trong đó 20% là người không làm kỹ thuật; AGENTS.md + Skills là bộ chỉ dẫn có thể kết hợp linh hoạt. Mức độ bằng chứng: cấp 1 (thông báo chính thức từ OpenAI). Nguồn: https://developers.openai.com/codex/skills

  • Claude Code (Anthropic, nửa đầu 2026). Hệ thống CLAUDE.md + .claude/rules/ + Skills; gia nhập chợ chính thức của Anthropic từ tháng 2/2026; kho Skills trên GitHub đạt 112.000 sao; vòng gọi vốn G tháng 2/2026 công bố doanh thu quy năm 2,5 tỷ USD. Mức độ bằng chứng: cấp 1. Nguồn: https://code.claude.com/docs/en/claude-directory

  • JetBrains AI Pulse Survey (2026.1). Khảo sát trên 10.000+ nhà phát triển chuyên nghiệp toàn cầu, được bản địa hóa bằng 8 ngôn ngữ; Claude Code đạt CSAT 91% / NPS 54 (cao nhất ngành); tỷ lệ áp dụng Claude Code tại nơi làm việc là 18% (tăng gấp 6 lần từ 3% trong 9 tháng), riêng Bắc Mỹ là 24%; Copilot đạt 29% tỷ lệ áp dụng tại nơi làm việc nhưng tăng trưởng đã chững lại; Cursor đạt 18%. Cấp độ bằng chứng: Cấp 1. Nguồn: https://www.jetbrains.com/lp/tools/ai-tools/

  • Pragmatic Engineer Newsletter (2026.2). Khảo sát 15.000 nhà phát triển; 46% chọn Claude Code là công cụ “được yêu thích nhất”, Cursor 19%, Copilot 9%. Cấp độ bằng chứng: Cấp 1. Nguồn: https://newsletter.pragmaticengineer.com/

  • Alibaba Qoder (2025.8 → 2026.7). Ra mắt bởi Alibaba vào tháng 8/2025; ngày 15/5/2026, Qoder 1.0 nâng cấp thành Autonomous Agent Development Workbench; bao gồm Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; ngày 28/5/2026 ra mắt Cloud Agents (môi trường chạy agent được quản lý); ngày 21/7/2026 ra mắt Qoder Security; đến tháng 5/2026 đạt hơn 5 triệu người dùng toàn cầu; tích hợp CLI với DingTalk; ngày 20/5/2026, Tongyi Lima đổi tên thành Qoder CN. Mức độ bằng chứng: cấp 1. Nguồn: https://www.alibabacloud.com/en/marketplace/qoder；https://baike.baidu.com/en/item/Qoder/1427525

  • vibecoding.app / thebcms.com / tfir.io (nửa đầu 2026). Bộ lệnh Spec Kit năm giai đoạn, đánh giá so sánh công cụ SDD, phương pháp ghi chú EARS. Cấp độ bằng chứng: cấp hai (đánh giá bởi bên thứ ba). Nguồn: https://vibecoding.app/blog/spec-kit-review；https://thebcms.com/blog/spec-driven-development

  • EU AI Act / Code of Practice (áp dụng đầy đủ từ 2.8.2026). Hạn chót tuân thủ cho hệ thống AI rủi ro cao là 2.8.2026; các mô hình GPAI hiện hành được gia hạn đến 2.8.2027; mức phạt tối đa lên tới 35 triệu EUR hoặc 7% doanh thu toàn cầu; Điều 9-15 quy định về quản lý rủi ro, quản trị dữ liệu, minh bạch tài liệu, giám sát con người, độ chính xác và độ tin cậy. Cấp độ bằng chứng: Cấp 1 (quy định pháp luật + phân tích tuân thủ cấp hai). Nguồn: https://artificialintelligenceact.eu/code-of-practice-overview; https://www.surecloud.com/resource-hub/eu-ai-act-complete-compliance-guide

  • Báo cáo Qodo về chất lượng mã nguồn AI (2025). 44% nguyên nhân gốc rễ của sự cố là do thiếu ngữ cảnh. Cấp độ bằng chứng: Cấp 2 (báo cáo từ nhà cung cấp). Nguồn: https://www.qodo.ai/reports/state-of-ai-code-quality/

Phụ lục A: Ánh xạ công cụ theo ngành (tham khảo triển khai nửa đầu 2026)

Viễn thông / Nhà mạng: AT&T, Verizon, NTT, KDDI, Deutsche Telekom, Telefónica, Vodafone. Bốn nhà mạng lớn tại Việt Nam (Viettel, Vinaphone, MobiFone, Vietnamobile) đều có thể tham chiếu mô hình SDD.

Ngân hàng Việt Nam tham chiếu: Vietcombank, BIDV, VietinBank, ACB, Techcombank, MB Bank. Hệ thống core banking có logic đối soát lâu năm, đặc biệt là các ngân hàng như Vietcombank với hệ thống lõi kế thừa nhiều thập kỷ.

Sản xuất: Một số tập đoàn sản xuất lớn tại Việt Nam (VinGroup, THACO, Hoa Phat) tham chiếu mô hình.

Bán lẻ / Thương mại điện tử: Shopee, Lazada, Tiki, Sendo — tích hợp quy trình đặc tả cho các module đối soát đơn hàng, kiểm soát khuyến mãi.

Mức tuân thủ tối thiểu cho ngành tài chính Việt Nam (theo i18n-compliance-mapping §1.19):

  • Đánh giá xuất dữ liệu xuyên biên giới: Nghị định 13/2023/NĐ-CP (Bộ Công an — MPS).
  • Bảo vệ an ninh mạng cấp độ: Luật An toàn thông tin mạng 2015 + Nghị định 85/2016 (Bộ Thông tin và Truyền thông — MIC), hệ thống bốn cấp độ.
  • Quản trị AI tạo sinh: Nghị định 13/2023 (mục quyết định tự động) + đề xuất MIC về AI.
  • Bảo vệ dữ liệu cá nhân: Nghị định 13/2023/NĐ-CP (MPS) — đây là PDPL đầu tiên của Việt Nam, áp dụng cơ chế đăng ký xuyên biên giới.
  • An ninh mạng: Luật An ninh mạng 2018 (MPS) — bắt buộc lưu trữ nội đị + kiểm duyệt xuyên biên giới.

Tham khảo: i18n-compliance-mapping.md §1.19 (vi — Việt Nam), §3.1 (bảo vệ cấp độ — fallback), §3.2 (quản trị thuật toán — fallback).

]]> Tỷ lệ lỗi code AI gấp 1,7 lần, lỗ hổng bảo mật gấp 2,74 lần — AI không thấy được quy tắc của bạn. 2026 H1 năm nền tảng đồng loạt chuyển sang spec-driven.