---
title: "Comprender en orden la ingeniería de arneses, bucles y grafos de agentes de IA"
locale: es
category: knowledge_base
category_name: "Base de conocimiento"
translation_status: reviewed
license: cc_by
author: "Equipo editorial de Injoys"
source_url: https://injoys.com/es/articles/ai-agent-harness-loop-graph-engineering
published_at: 2026-08-16T00:45:12+09:00
---

# Comprender en orden la ingeniería de arneses, bucles y grafos de agentes de IA

> El arnés diseña el entorno de trabajo y los mecanismos de control del agente; el bucle, las reglas de repetición y finalización; y el grafo, los estados permitidos y las rutas de transición. Es más preciso entender estos tres términos como perspectivas prácticas para gestionar la autonomía y los riesgos de los agentes de IA que como una clasificación oficial estandarizada.

## Key Points

- La ingeniería de arneses consiste en diseñar como un único entorno de ejecución el contexto externo al modelo, las herramientas, los permisos, la validación, los registros y los procedimientos de aprobación.
- La ingeniería de bucles define las condiciones, el presupuesto y los criterios de finalización para que el agente repita la planificación, la ejecución, la validación y la corrección.
- La ingeniería de grafos utiliza estados y reglas de transición para limitar o ajustar explícitamente las rutas que el agente puede elegir.
- Para la mayoría de las organizaciones, resulta más eficiente mejorar primero el arnés y el sistema de evaluación de un solo agente que implementar un grafo multiagente complejo.
- Aprobar únicamente informes resumidos creados por la IA no es suficiente para el código de alto riesgo; también deben verificarse las pruebas, el alcance de los cambios, los límites de seguridad y los resultados originales.

A medida que los agentes de IA empiezan a asumir tareas de larga duración, resulta difícil obtener resultados estables solo con buenos prompts. Esto se debe a que también hay que diseñar qué información consulta el agente, qué herramientas utiliza, cuándo repite una acción, qué ruta sigue y en qué puntos debe obtener la aprobación de una persona.

Para explicar este problema suelen aparecer los términos **ingeniería de arnés**, **ingeniería de bucles** e **ingeniería de grafos**. No son estándares internacionales ni categorías académicas estrictamente consensuadas. Se solapan entre sí y su significado puede variar según el producto y el equipo de desarrollo. Por tanto, en lugar de memorizarlos como términos de moda de cada año, resulta más útil distinguirlos por la pregunta de control a la que intenta responder cada uno.

## Comparación de los tres conceptos de un vistazo

| Concepto | Pregunta clave | Principal objeto de diseño | Mecanismos representativos de prevención de fallos |
|---|---|---|---|
| Ingeniería de arnés | ¿En qué entorno y bajo qué reglas trabaja el agente? | Contexto, herramientas, permisos, sandbox, hooks, registros, aprobación, evaluación | Privilegios mínimos, aprobación de comandos peligrosos, ejecución de pruebas, selección de contexto |
| Ingeniería de bucles | ¿Qué se repite y cuándo se detiene? | Ciclo de planificación, ejecución y verificación, procesamiento de eventos, reintentos, presupuesto, condiciones de finalización | Número máximo de iteraciones, límites de tiempo y tokens, evaluación del progreso, derivación en caso de fallo |
| Ingeniería de grafos | ¿Qué estados y rutas se permiten? | Nodos, estados, transiciones, bifurcaciones, procesamiento paralelo, checkpoints | Transiciones prohibidas, validación de estados, nodos de aprobación, rutas de recuperación |

En pocas palabras, **el arnés define el entorno y los límites**, **el bucle define las reglas de repetición** y **el grafo define la estructura de las rutas posibles**. En un sistema real, puede haber un bucle dentro de un nodo del grafo y todo el grafo puede ejecutarse dentro de un mismo arnés.

## Cómo han evolucionado los métodos de control de agentes

### Agentes iniciales: los flujos de trabajo predefinidos complementaban la autonomía

Los primeros agentes de IA generativa solían olvidar sus objetivos durante las tareas largas, repetir llamadas incorrectas a herramientas o generar resultados sin fundamento. Como respuesta, los desarrolladores dividieron las tareas grandes en pasos pequeños y fijaron las entradas y salidas de cada paso.

Con este método, una persona redacta todo el procedimiento en forma de cadena, diagrama de flujo o máquina de estados, mientras que el LLM se encarga de tareas limitadas como la clasificación, la extracción, el resumen o la redacción de borradores. Los frameworks como LangGraph se utilizan para representar bifurcaciones, ciclos, checkpoints e intervención humana manteniendo el estado.

Sin embargo, la orquestación basada en grafos no es un método obsoleto que terminara en un año concreto. Los grafos explícitos siguen siendo adecuados para tareas en las que son importantes la capacidad de auditoría, la reproducibilidad, el cumplimiento normativo o unos procedimientos de recuperación precisos.

### Mejora del rendimiento de los modelos: de rutas fijas al uso dinámico de herramientas

A medida que mejoraron el uso de herramientas y la capacidad de razonamiento, un solo agente pudo seleccionar acciones como buscar, editar código, ejecutar pruebas y leer archivos según la situación. Los enfoques de la familia ReAct constituyen una estructura representativa que alterna razonamiento, acción y observación.

Este cambio redujo la carga de tener que definir por adelantado todas las bifurcaciones. Por otro lado, adquirió mayor importancia gestionar la información que lee el agente, los permisos que posee, el coste de ejecución y el método de recuperación ante errores. En este contexto, la ingeniería de contexto y la ingeniería de arnés pasan al centro del trabajo práctico.

### Tareas largas y múltiples agentes: recombinación de bucles y grafos

En las tareas largas, la planificación, ejecución y verificación repetitivas son más importantes que una sola llamada al modelo. Cuando participan varios agentes, también hay que especificar los roles, el formato de los entregables, los permisos y las condiciones de finalización. Al mismo tiempo, dejar los bucles autónomos completamente desatendidos puede provocar una explosión de costes, reintentos infinitos, manipulación de recompensas y optimización de objetivos incorrectos.

Por eso, los sistemas de agentes modernos se diseñan para **combinar los tramos en los que se permite la autonomía con aquellos que se controlan de forma determinista**, en lugar de eliminar la autonomía. No se trata de un simple regreso a las cadenas fijas del pasado, sino de rodear una ejecución flexible con estados, transiciones y políticas.

Este cambio es más una modificación del énfasis del diseño que una cronología exacta. Los grafos, los bucles y los arneses han coexistido desde el principio y siguen utilizándose conjuntamente.

## Qué aborda la ingeniería de arnés

El arnés no es el propio modelo base, sino **el sistema de ejecución que rodea al modelo para que realice tareas reales**. Incluso utilizando el mismo modelo, la tasa de éxito, el coste, la seguridad y la reproducibilidad pueden variar considerablemente en función del arnés.

### Principales componentes de un arnés

1. **Sistema de instrucciones**: instrucciones del sistema, reglas del repositorio, estándares de codificación, prioridades y acciones prohibidas
2. **Suministro de contexto**: búsqueda, selección de archivos, resúmenes, memoria e incorporación de documentos en el momento necesario
3. **Interfaz de herramientas**: edición de archivos, terminal, navegador, base de datos y API externas
4. **Permisos y aislamiento**: alcance de lectura y escritura, acceso a información secreta, restricciones de red y sandbox
5. **Mecanismos de verificación**: pruebas, linter, comprobación de tipos, validación de esquemas y verificación de hechos
6. **Aprobación humana**: aprobación de acciones difíciles de revertir, como despliegues, pagos, eliminaciones y transmisiones externas
7. **Observabilidad**: historial de llamadas, costes, latencia, errores, historial de cambios y fundamento de las decisiones
8. **Política de recuperación**: reintentos, restauración del estado anterior, interrupción de tareas y derivación a una persona responsable

Los archivos de instrucciones de proyecto o los hooks de Claude Code pueden considerarse ejemplos de componentes de un arnés. Sin embargo, una sola función de un producto concreto no representa todo el arnés.

### Diferencia respecto a la ingeniería de contexto

La ingeniería de contexto optimiza qué información e instrucciones se introducen en la llamada actual al modelo. Incluye recuperar mediante búsquedas solo los documentos relevantes, resumir conversaciones antiguas, guardar el estado de la tarea en archivos externos y separar el contexto de cada subtarea.

La ingeniería de arnés tiene un alcance más amplio. Además del contexto, abarca los permisos de las herramientas, el entorno de ejecución, las aprobaciones, la verificación, el registro y los límites de coste. Por tanto, la ingeniería de contexto es una parte esencial del arnés, pero no es preciso utilizar ambos términos como si significaran exactamente lo mismo.

## La clave de la ingeniería de bucles son las condiciones de finalización

Un bucle hace que el agente compruebe el resultado después de generarlo y vuelva a intentarlo si es insuficiente. Lo importante no es la repetición en sí, sino **la definición del progreso y las condiciones de interrupción**.

### Tipos representativos de bucles

- **Bucle de verificación**: después de crear un borrador, lo comprueba mediante pruebas o criterios de evaluación y corrige los elementos que hayan fallado.
- **Bucle basado en eventos**: inicia una tarea cuando se produce un evento externo, como un correo electrónico, una notificación, un cambio de código o datos de sensores.
- **Bucle de exploración**: investiga varias hipótesis o fuentes y ajusta el alcance de la exploración hasta reunir pruebas suficientes.
- **Bucle de mejora**: selecciona la siguiente estrategia a partir de resultados y evaluaciones anteriores. Optimizar una única puntuación puede provocar manipulación de recompensas, por lo que se necesitan varios criterios de evaluación y revisión humana.
- **Bucle de recuperación**: clasifica la causa del error, reintenta dentro del alcance permitido y, si no logra resolverlo, lo deriva a una persona.

### Contratos necesarios para un bucle seguro

Un contrato entre agentes no es un contrato legal, sino una especificación de ejecución que define las entradas, las salidas y las responsabilidades. Conviene incluir los siguientes elementos.

| Elemento del contrato | Contenido que debe especificarse |
|---|---|
| Objetivo | Resultado que debe completarse y alcance excluido |
| Entrada | Datos que pueden utilizarse, vigencia y nivel de confianza |
| Salida | Esquema JSON, formato del documento, pruebas obligatorias y resultados de las pruebas |
| Permisos | Herramientas permitidas, alcance de los archivos y permisos de transmisión externa y modificación |
| Verificación | Pruebas y criterios de evaluación que deben superarse |
| Presupuesto | Tokens, tiempo, número de llamadas y cantidad de tareas paralelas |
| Finalización | Condiciones de éxito, ausencia de progreso, agotamiento del presupuesto y detección de riesgos |
| Derivación | Qué persona o agente se hace cargo en caso de fallo |

Si las condiciones de finalización son ambiguas, el agente puede considerar que la tarea está progresando aunque solo esté modificando frases o repitiendo la misma búsqueda. En lugar de establecer únicamente un número máximo de iteraciones, es mejor considerar conjuntamente la calidad del resultado, el aumento de información nueva, la evolución de los errores y el coste.

## La ingeniería de grafos estructura los límites de la autonomía

Un grafo representa una tarea mediante nodos y conexiones. Un nodo puede corresponder a una llamada al modelo, la ejecución de una herramienta, una aprobación humana o un proceso de verificación, mientras que las conexiones indican la siguiente acción en función del estado.

### Diferencia entre cadenas y grafos

- **Una cadena** es adecuada para procedimientos lineales que van de A a B y de B a C.
- **Un grafo** es adecuado para tareas que requieren bifurcaciones condicionales, repeticiones, ejecución paralela, recuperación ante fallos y guardado intermedio.
- **Un grafo dinámico** permite que el modelo proponga la siguiente subtarea o ruta durante la ejecución.
- **Un grafo restringido** hace que, aunque el modelo elija, solo pueda moverse entre los nodos y las transiciones permitidos.

El propósito del diseño moderno de grafos no consiste en que una persona decida de antemano todas las acciones. Consiste en incorporar a la estructura **condiciones invariantes que deben respetarse**, como obligar a pasar por un nodo de aprobación antes de eliminar datos o impedir la transición al estado de despliegue cuando las pruebas se encuentran en estado fallido.

### Indicadores de que se necesita un grafo

Si se cumplen varias de las siguientes condiciones, merece la pena considerar un grafo explícito.

- Existe un punto claro de recuperación al que volver después de un fallo.
- Hay una etapa que requiere obligatoriamente la aprobación de una persona.
- Hay que ejecutar varias tareas en paralelo y después combinar los resultados.
- Las herramientas o los permisos disponibles varían según el estado.
- Es necesario auditar o reproducir toda la ruta de ejecución.
- Un bucle de un solo agente repite el mismo fallo.

Crear un grafo incluso para resumir un documento sencillo o realizar una única transformación de datos puede limitarse a aumentar la complejidad.

## Orden de aplicación práctica: empezar por el arnés y ampliar según sea necesario

Para la mayoría de los equipos, el siguiente orden es realista.

1. **Definir una sola tarea y sus criterios de éxito.** Primero se recopilan las entradas, los resultados esperados y los casos de fallo.
2. **Crear un arnés mínimo.** Se proporcionan únicamente el contexto y las herramientas necesarios, y se establecen permisos, pruebas, registros y límites de coste.
3. **Construir un conjunto de evaluación.** Además de casos normales, debe incluir solicitudes ambiguas, documentos incorrectos, errores de herramientas e intentos de exceder los permisos.
4. **Convertir en bucles los puntos que necesitan repetición.** Solo se permiten reintentos en los tramos donde la verificación y la corrección mejoran realmente la calidad.
5. **Elevarlo a grafo cuando las bifurcaciones y la recuperación sean complejas.** Se especifican los estados y las transiciones, y se colocan nodos de aprobación antes de las acciones peligrosas.
6. **Utilizar múltiples agentes solo cuando la división del trabajo resulte beneficiosa.** Si no son necesarios la exploración paralela o diferentes roles especializados, un solo agente puede ser más sencillo y económico.

## Diferencias de aplicación en codificación e investigación

| Elemento | Tareas de codificación | Tareas de investigación |
|---|---|---|
| Capacidad de verificación | La verificación automática mediante pruebas, compilación y comprobación de tipos es relativamente sencilla | Hay que evaluar de forma integral la calidad de las fuentes, las omisiones y las pruebas contradictorias |
| Valor de la exploración dinámica | Puede ser limitado si el alcance de los cambios está claro | Es elevado al comparar distintas rutas de búsqueda e hipótesis |
| Principales riesgos | Cambios incorrectos, vulnerabilidades de seguridad y código adaptado únicamente a las pruebas | Afirmaciones sin fuentes, materiales duplicados y sesgo de confirmación |
| Controles adecuados | Limitación del alcance del repositorio, pruebas, revisión del diff y aprobación del despliegue | Registro de fuentes, búsqueda independiente, exploración de pruebas contrarias y verificación de citas |

No puede afirmarse que los flujos de trabajo dinámicos sean siempre ineficientes para la codificación y siempre ventajosos para la investigación. Una migración a gran escala que pueda probarse puede ser adecuada para un agente autónomo, mientras que un procedimiento fijo de investigación puede ser más eficiente para consultar un hecho cuya respuesta está clara. Las variables clave, más que el ámbito, son **la claridad del objetivo, la posibilidad de verificación automática, el espacio de exploración y el coste de los errores**.

## La revisión de código no desaparece: cambia la unidad de revisión

Cuando un agente escribe código, el desarrollador pasa a desempeñar en mayor medida la función de supervisar los requisitos, el diseño, los resultados de las pruebas, el alcance de los cambios y los riesgos, en lugar de introducir directamente cada línea. Los resúmenes de Pull Request y los informes de los agentes pueden acelerar la revisión.

Sin embargo, leer únicamente el resumen y aprobar no constituye una opción predeterminada segura. Los cambios que el agente haya omitido o la lógica que haya entendido incorrectamente pueden no aparecer tampoco en el resumen. En las siguientes situaciones, es necesario revisar directamente el diff original y el código relacionado.

- Cambios en autenticación, pagos, datos personales, cifrado o control de acceso
- Cambios en el esquema de la base de datos o migraciones irreversibles
- Código sensible al rendimiento y la concurrencia
- Refactorizaciones a gran escala fuera del alcance de las pruebas
- Cambios en dependencias externas, configuración de despliegue o tratamiento de información secreta
- Casos en los que la explicación del agente no coincide con el diff real

Human-in-the-loop no significa que una persona pulse un botón como mera formalidad. También implica proporcionar pruebas de los cambios, resultados de las pruebas, posibles fallos y procedimientos de reversión para que la persona pueda tomar una decisión.

## Errores frecuentes

### Múltiples agentes sin propósito

Aumentar el número de agentes genera costes de coordinación de roles, llamadas duplicadas, transferencia de contexto y combinación de resultados. Si no existe la necesidad de explorar en paralelo desde distintas perspectivas o de separar el contexto, es mejor utilizar un solo agente.

### Flujos de trabajo dinámicos sin límites

Si se permite que un agente siga creando subtareas, el coste de los tokens y las llamadas a herramientas aumenta rápidamente. El coste está determinado aproximadamente por la suma del coste de los tokens de entrada y salida de cada etapa, el coste de las herramientas, el número de agentes paralelos y la cantidad de iteraciones. El número de llamadas, la cantidad de ejecuciones simultáneas, el presupuesto total y el tiempo máximo de ejecución deben limitarse por separado.

### Optimizar un solo indicador de evaluación

Si el único objetivo es la tasa de superación de las pruebas, puede producirse una optimización incorrecta, como debilitar las pruebas u ocultar el tratamiento de excepciones. Es necesario utilizar conjuntamente la calidad, la seguridad, el alcance de los cambios, el coste, la latencia y la evaluación humana.

### Confundir la incorporación de documentos con el fine-tuning

Los resultados pueden cambiar de forma persistente mediante la búsqueda de documentos o las instrucciones del proyecto, pero eso no significa que cambien los pesos del modelo. En un sentido amplio, puede describirse como un efecto de aprendizaje del sistema, pero, estrictamente hablando, es una adaptación mediante memoria externa y contexto. Hay que conservar los documentos o el índice de búsqueda para que los cambios se mantengan también en la siguiente ejecución.

## Evaluación, seguridad y economía que suelen pasarse por alto durante la operación

El diseño de agentes no termina con un diagrama de arquitectura. En la operación real es importante contar con **un sistema que mida lo que realmente ocurrió, más que aquello que se permitió**.

### Indicadores operativos mínimos

- Tasa de éxito de las tareas y tasa de correcciones humanas
- Coste de modelos y herramientas por tarea y tiempo total de ejecución
- Número de iteraciones y proporción de llamadas consumidas sin progreso
- Número de solicitudes de aprobación, rechazos e intentos de exceder los permisos
- Llamadas incorrectas a herramientas y tasa de éxito de la recuperación
- Proporción de resultados entregados sin fuentes ni pruebas
- Grado de variación de los resultados ante una misma entrada

### Condiciones invariantes necesarias para la seguridad

- Las instrucciones de documentos externos no tienen mayor prioridad que las políticas del sistema.
- La información secreta no se expone innecesariamente en las entradas del modelo ni en los registros.
- Los permisos de lectura se separan de los permisos de escritura, eliminación y despliegue.
- Las transmisiones externas y las acciones irreversibles están sujetas a una aprobación adicional o una comprobación de políticas.
- Se impide que el agente modifique arbitrariamente sus propios criterios de evaluación, pruebas o registros de auditoría.

Es más seguro imponer estas condiciones invariantes mediante un sandbox, controles de acceso, transiciones de grafos y verificadores independientes que mediante una sola frase en un prompt. La gestión de riesgos de la IA generativa debe abarcar no solo la precisión del modelo, sino también el entorno operativo, la supervisión humana y la respuesta ante incidentes.

## Qué concepto se debe aprender primero

En el trabajo práctico actual, lo primero que debe aprenderse es la ingeniería de arnés. Contar con un contexto preciso, privilegios mínimos, verificación automática, registros, aprobaciones y límites de coste puede reducir muchos de los fallos de un solo agente.

Después, se añaden bucles con condiciones de finalización a las tareas en las que la repetición mejora la calidad. Cuando las bifurcaciones, el procesamiento paralelo, la recuperación y los procedimientos de aprobación se vuelven complejos, se especifican mediante un grafo. Antes que adoptar términos complejos, la prioridad es expresar de forma medible los objetivos, permisos, pruebas, costes y condiciones de interrupción del agente.

## FAQ

### ¿En qué se diferencia la ingeniería de arneses de la ingeniería de prompts?
La ingeniería de prompts se ocupa principalmente de las instrucciones y formulaciones que se proporcionan al modelo. La ingeniería de arneses es el diseño de un entorno de ejecución más amplio que incluye no solo los prompts, sino también la recuperación de contexto, las herramientas, los permisos, los entornos aislados, las pruebas, los registros, la aprobación humana y la recuperación de errores.

### ¿La ingeniería de contexto y la ingeniería de arneses significan lo mismo?
No. La ingeniería de contexto se centra en seleccionar, recuperar, resumir y organizar la información que el modelo necesita conocer en ese momento. La ingeniería de arneses, además de la gestión del contexto, aborda conjuntamente los permisos, las herramientas, la validación, los límites de costes y las políticas operativas.

### ¿Cuál es la diferencia más importante entre un bucle y un grafo?
Un bucle define qué se repite y cuándo se detiene, como la planificación, la ejecución, la verificación y la corrección. Un grafo define qué estados existen y cómo se puede pasar de un estado a otro. Un grafo puede contener uno o más bucles.

### ¿Todos los agentes de IA necesitan un framework de grafos como LangGraph?
No. Para tareas sencillas y breves, un solo agente y un arnés mínimo pueden ser suficientes. El valor de un grafo aumenta cuando se requieren bifurcaciones condicionales, procesamiento en paralelo, almacenamiento intermedio, recuperación ante fallos, aprobación humana o auditoría de las rutas de ejecución.

### ¿Los sistemas multiagente siempre tienen un mejor rendimiento que los de un solo agente?
No. Los sistemas multiagente son útiles cuando se necesitan investigación en paralelo, distintos roles especializados y separación del contexto. Si los roles se solapan o los objetivos son ambiguos, es posible que solo aumenten el trabajo duplicado, los errores de transferencia, las demoras y los costes.

### ¿Cómo se evita que el bucle de un agente se repita indefinidamente?
Deben establecerse no solo un número máximo de iteraciones, sino también presupuestos de tiempo, tokens, llamadas a herramientas y costes. El sistema debe considerar que no hay progreso cuando no se obtiene información nueva ni se reducen los errores, y debe estar diseñado para detenerse o derivar el caso a una persona cuando se alcance un umbral determinado.

### ¿Basta con revisar únicamente el resumen de una Pull Request del código escrito por una IA?
El resumen es solo material de apoyo y no sustituye los cambios originales. En cambios de alto riesgo, como los relacionados con la autenticación, los pagos, los datos personales, la migración de datos y la configuración del despliegue, se deben revisar directamente el diff real, la cobertura de las pruebas, las dependencias y el procedimiento de reversión.

### Si se proporcionan continuamente documentos de la empresa, ¿significa que el modelo ha aprendido?
Aunque los resultados pueden cambiar de manera persistente, eso no significa que se hayan actualizado los pesos del modelo. Se trata de una adaptación a nivel de sistema que conserva documentos externos, índices de búsqueda, memoria e instrucciones para volver a proporcionarlos en la siguiente ejecución, y debe distinguirse del ajuste fino en sentido estricto.

### ¿La ingeniería de grafos supone volver a los flujos de trabajo fijos de los primeros tiempos?
No necesariamente. Los grafos modernos se asemejan más a un control híbrido que permite que el agente planifique de forma autónoma y seleccione herramientas en algunos tramos, al tiempo que limita explícitamente las transiciones peligrosas y los puntos de aprobación obligatorios.

### ¿Qué es lo primero que debe definirse al diseñar un arnés?
Primero deben definirse los criterios de éxito de la tarea y el coste de los fallos. Después, es recomendable proporcionar solo el contexto y las herramientas necesarios y establecer privilegios mínimos, validación automática, registros de ejecución, límites de costes y condiciones de detención.

## Sources

- [Anthropic — Creación de agentes eficaces](https://www.anthropic.com/research/building-effective-agents)
- [Anthropic — Ingeniería de contexto eficaz para agentes de IA](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
- [Anthropic — Cómo construimos nuestro sistema de investigación multiagente](https://www.anthropic.com/engineering/multi-agent-research-system)
- [Descripción general de LangGraph](https://docs.langchain.com/oss/python/langgraph/overview)
- [ReAct: Sinergia entre el razonamiento y la acción en los modelos de lenguaje](https://arxiv.org/abs/2210.03629)
- [NIST AI 600-1 — Marco de gestión de riesgos de la inteligencia artificial: perfil de la inteligencia artificial generativa](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf)

## Images

![Sistema de IA central rodeado de flechas cíclicas y una red de nodos de éxito y error](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6ODI0NSwicHVyIjoiYmxvYl9pZCJ9fQ==--3a03e254c3d24990df4c3fc46145a5db24e457ba/ai-eb0e40fe.webp)
![Un robot de IA pasa de un entorno seguro a un bucle de herramientas, un grafo ramificado y una puerta de alerta](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6ODI1MSwicHVyIjoiYmxvYl9pZCJ9fQ==--cea797c99aabaa4b8f760264327fe2ee8b34b423/ai-23d7d97a.webp)