Estándares de ejecución con IA
Las reglas y expectativas para delegar trabajo a la IA en toda la organización.
Política de Expectativas Organizacionales
El principio operativo detrás de estos estándares es la Regla de Traducción Universal: reemplazar "el humano produce el artefacto" con "el humano define la spec → el sistema produce el artefacto".
Principio central
La IA se trata como un trabajador autónomo, no como un chatbot.
Todo trabajo asignado a la IA debe ser ejecutable sin supervisión humana en tiempo real durante la ejecución. La clarificación previa a la ejecución (el agente aflorando supuestos y haciendo preguntas calibradas antes de producir resultado) está permitida y, en mayor madurez, se espera. Ver Laboratorio de IA § Las cinco etapas para el patrón operacional.
Capas de trabajo obligatorias
Cada flujo de trabajo habilitado por IA debe definir las cuatro capas de entrada (1-4). La Capa 5 (Diseño de procesos) las extiende con la pipeline operacional que consume las entradas; es obligatoria para el trabajo Tier 3 / Peldaño 5 y opcional por debajo.
Capa 1 – Diseño de prompts (habilidad base)
Los empleados deben:
- escribir instrucciones claras
- especificar el formato
- incluir ejemplos cuando sea útil
- resolver ambigüedades de antemano
Nivel mínimo: el resultado de la IA debe requerir ≤20% de corrección.
Capa 2 – Ingeniería de contexto
Cada equipo debe mantener un archivo de contexto estructurado que contenga:
- objetivos
- restricciones
- terminología
- estándares de calidad
- documentos relevantes
- reglas de acceso a herramientas
Requisito: las tareas de IA deben cargar este contexto antes de la ejecución.
Capa 3 – Ingeniería de intención
Cada flujo de trabajo debe definir:
- jerarquía de objetivos
- reglas de compensación
- condiciones de escalación
- qué puede decidir la IA versus qué debe escalar
Ningún agente puede ejecutarse sin intención definida.
Capa 4 – Ingeniería de especificaciones (estándar más alto)
Todas las tareas no triviales deben tener una especificación escrita.
Componentes requeridos de la spec:
- declaración del problema
- alcance
- entradas
- restricciones
- criterios de aceptación
- condiciones de fallo
- pruebas de éxito
- definición de completitud
Regla: si el éxito no puede verificarse objetivamente, la tarea no está lista para especificarse.
Para los códigos brownfield, la inversión importa: el código ya existe y las especificaciones deben extraerse de ingeniería inversa antes de que el trabajo spec-first pueda reanudarse. Ver estrategia brownfield para el flujo de trabajo spec-from-code.
Capa 5 – Diseño de procesos
La capa operacional. Una vez que una spec funciona, la siguiente pregunta es la pipeline que la ejecuta. El diseño de procesos es la disciplina de diseñar flujos de trabajo restringidos y por fases dentro de los cuales la IA opera de manera consistente: distinta de la ingeniería de prompts y de la escritura de specs en sí. Es la capa que distingue el trabajo Tier 3 / Peldaño 5 del trabajo Tier 2 / Peldaño 4.
El vocabulario, tomado de Building Effective Agents de Anthropic:
- Encadenamiento de prompts: pasos secuenciales de un solo prompt con validación intermedia
- Enrutamiento: clasificar la tarea, despachar al prompt o flujo de trabajo especializado apropiado
- Paralelización: ejecutar subtareas independientes concurrentemente, agregar resultados
- Orquestador-trabajadores: un agente líder descompone la tarea y despacha trabajadores
- Evaluador-optimizador: un generador emparejado con un evaluador separado que puntúa e itera
- Agentes autónomos: exploración abierta con uso de herramientas y bucles de retroalimentación
Regla de decisión: empieza con un solo prompt; añade flujo de trabajo cuando sea necesario; añade multiagente solo cuando el valor por tarea justifique el sobrecoste de tokens (los agentes típicos usan ~4× tokens del chat; multiagente ~15×, según Anthropic, 2025). No recurras a multiagente porque suena sofisticado.
Antipatrones:
- Pitfall: Mega-prompt único
Combina modos de fallo; imposible de depurar.
- Pitfall: Multiagente por sí mismo
Caro, frágil, a menudo un solo agente lo hace igual de bien.
- Pitfall: Volcado de contexto
Más contexto suele ser peor contexto.
- Pitfall: Omitir las evaluaciones
Sin evaluaciones, los sistemas de IA se degradan silenciosamente.
- Pitfall: Optimizar prompts cuando el problema es el contexto
Atribución errónea del modo de fallo.
Las cuatro capas de entrada (Prompt → Contexto → Intención → Spec) describen lo que el humano prepara antes de la delegación. La Capa 5 describe la pipeline que consume esas entradas. En T3/R5 la pipeline también es un artefacto diseñado, y las puertas de validación dentro de ella están graduadas por riesgo (HITL / HOTL / HOOTL).
Primitivas de especificación (habilidades aprendibles)
La ingeniería de especificaciones se construye a partir de cinco primitivas. Cada una es una habilidad distinta a practicar. Para ejemplos, plantillas y especificaciones trabajadas para diferentes roles, ver la Guía de especificación.
Primitiva 1 – Declaraciones de problema autocontenidas
Enuncia el problema con suficiente contexto para que la tarea sea resoluble sin que el agente busque más información. Muestra los supuestos ocultos. Articula las restricciones que normalmente dejas implícitas.
Ejercicio de entrenamiento: toma una solicitud que harías normalmente de manera conversacional y reescríbela como si el destinatario nunca hubiera visto tu proyecto, no conociera tu terminología y no tuviera acceso a nada más allá de lo que incluyes.
Primitiva 2 – Criterios de aceptación
Define cómo se ve el resultado terminado para que un observador independiente pueda verificar el resultado sin hacer preguntas. Si no puedes escribir tres oraciones que verifiquen la completitud, no entiendes la tarea lo suficientemente bien como para delegarla.
Primitiva 3 – Arquitectura de restricciones
Define cuatro categorías para cada tarea:
- Debe – requisitos no negociables
- No debe – acciones o resultados prohibidos
- Prefiere – orientación cuando existen múltiples enfoques válidos
- Escalar – condiciones donde el agente debe detenerse y preguntar
Primitiva 4 – Descomposición
Divide las tareas en componentes que puedan ejecutarse de forma independiente, probarse de forma independiente e integrarse de manera predecible. Granularidad objetivo: subtareas de ≤2 horas con límites claros de entrada/salida, cada una verificable por sí sola.
Primitiva 5 – Diseño de evaluación
Para cada tarea recurrente de IA, construye 3-5 casos de prueba con resultados conocidos como buenos. Ejecútalos después de actualizaciones del modelo para detectar regresiones. Los resultados se juzgan por métricas, no por apariencia.
Una spec válida debe pasar las cinco: autocontenida, verificable, restringida, descomponible, evaluable.
Lista de verificación de preparación para delegar
Antes de asignar trabajo a la IA, los empleados deben confirmar:
- Entiendo la tarea completamente
- Puedo definir el éxito objetivamente
- Puedo listar los casos de fallo
- Puedo describir las restricciones
- Puedo verificar los resultados sin interpretación
Si alguna respuesta = no → no delegues todavía.
Modelo de responsabilidad por fallos
Los fallos se atribuyen por capa:
| Tipo de fallo | Causa raíz |
|---|---|
| Resultado deficiente | Problema de prompt |
| Resultado irrelevante | Problema de contexto |
| Dirección equivocada | Problema de intención |
| Resultado incompleto | Problema de spec |
| Resultado dañino | Problema de permiso / radio de impacto: el agente no debería haber podido tomar esta acción |
| Resultado no detectado | Problema de puerta de validación: la postura de supervisión incorrecta para el radio de impacto de esta acción (ver puertas graduadas por riesgo) |
| Dirección equivocada defendida con confianza | Clarificación omitida: el agente se comprometió antes de que los supuestos fueran aflorados |
Los equipos deben corregir la capa responsable, no reintentar prompts.
Roles organizacionales
Cada sistema de IA en producción debe tener:
- Propietario de Spec: responsable de la calidad de la especificación, los criterios de aceptación y qué significa "listo"
- Propietario de Contexto: responsable de los archivos de contexto (CLAUDE.md / AGENTS.md), la frescura del contexto y el alcance de las herramientas y habilidades
- Propietario de Evaluación: responsable de la suite de evaluaciones, la detección de regresiones y las métricas de calidad
- Responsable de permisos: responsable de lo que cada agente puede y no puede hacer, y del nivel de la puerta de validación (HITL / HOTL / HOOTL) por clase de acción
Una persona puede ocupar múltiples roles inicialmente. El rol del Responsable de permisos se vuelve crítico tan pronto como los agentes tocan sistemas de producción con efectos secundarios irreversibles.
Estos cuatro roles gobiernan un sistema de IA en producción. Son distintos de los tres roles requeridos para gobernar la transformación con IA de un equipo: ver Liderar la transformación § Roles organizacionales.
Estándar de documentación
Todos los documentos internos deben escribirse como si un agente los fuera a ejecutar.
Los documentos deben:
- declarar supuestos
- definir términos
- especificar resultados
- incluir restricciones
- evitar conocimiento implícito
Regla resumida del ejecutivo
El pensamiento claro precede a la ejecución con IA.
Si no puedes especificarlo, no puedes automatizarlo.
← Volver al inicio · El marco de referencia · El Laboratorio de IA · Glosario