Mapa de IA en AWS: servicios, datos, agentes y operaciones
Contenido elaborado con ayuda de inteligencia artificial. Las fuentes se indican cuando corresponde.
Curso interactivo · gratuito · 7 módulos
Mapa de IA en AWS: servicios, datos, agentes y operaciones
Convierte el mapa «AWS AI Ecosystem (2026)», firmado Robert van Vlijmen, en una arquitectura comprensible. Curso conceptual con ejercicios simulados: no crea recursos de AWS ni exige tarjeta. Los servicios reales pueden tener costes, límites de región y requisitos de acceso.
Aprende a tu ritmo: abre una lección, recorre su esquema vertical, resuelve el caso y comprueba la explicación. No necesitas instalar programas ni crear cuentas. Los ejercicios son simulaciones; no ejecutan servicios ni generan costes.
Contenido desarrollado con ayuda de IA a partir de una infografía aportada y documentación enlazada. Redacción y esquemas propios; no se reproduce la captura original. Los mapas son orientativos y no constituyen una clasificación oficial ni un ranking de calidad.
0 de 7 comprobaciones superadas.
1. IA responsable: identidad, permisos y protección
La primera decisión es quién puede acceder a qué. El modelo no debe convertirse en administrador de toda la cuenta.
- IAM Identity Center organiza acceso de personas; IAM define identidades y permisos; KMS gestiona claves de cifrado.
- El mapa sitúa Bedrock, SageMaker Model Registry y Model Cards junto a gobernanza: registrar versiones y documentar límites ayuda a gestionar el ciclo de vida.
- Bedrock Guardrails actúa sobre contenido; AgentCore Policy e Identity cubren aspectos de autorización e identidad de agentes. Son controles complementarios.
- Amazon Comprehend puede analizar texto y Macie ayuda a descubrir datos sensibles en S3. No sustituyen una política de tratamiento y acceso a datos.
El proceso, en vertical
- Identificar datos y usuarios
- Permisos mínimos por operación
- Cifrado y controles de contenido
- Registro de versiones y responsabilidades
- Pruebas de accesos permitidos y denegados
Decide y comprueba
¿Qué permiso necesita un asistente que solo consulta documentación?
Ver razonamiento
Limita los recursos y las operaciones. El permiso de lectura debe respetar también qué documentos puede ver cada usuario.
Aplica lo aprendido
Define dos permisos permitidos y dos prohibidos.
Comparar con una solución orientativa
Permitidos: recuperar fragmentos de un repositorio autorizado y consultar su versión. Prohibidos: borrar objetos y cambiar políticas IAM. Comprueba denegaciones además de casos positivos.
2. Gestión de datos: búsqueda, grafos y caché
Una misma aplicación puede necesitar datos transaccionales, búsqueda semántica y caché. No todos los almacenes resuelven el mismo problema.
- El mapa incluye S3 Vectors y OpenSearch Service para escenarios de recuperación; Aurora para datos relacionales y Neptune para grafos.
- MemoryDB y Redis aparecen junto a caché y estado; DocumentDB junto a documentos. Pinecone es una opción externa, no un servicio nativo equivalente a todos los anteriores.
- Bedrock Knowledge Bases integra flujos de recuperación con fuentes y almacenes compatibles. S3, FSx y EFS son opciones de almacenamiento con características distintas.
- Los permisos del repositorio de origen deben reflejarse en la recuperación. Conserva identificador de documento, versión y fecha.
El proceso, en vertical
- Inventario y clasificación de datos
- Ingesta y actualización
- Índice o almacén según consulta
- Filtro por permisos
- Recuperación con procedencia
Decide y comprueba
¿Qué elegirías para explorar relaciones entre entidades?
Ver razonamiento
Neptune ilustra la familia de grafos. Aun así, la decisión depende de consultas, volumen, mantenimiento y coste.
Aplica lo aprendido
Separa tres necesidades de un asistente de soporte.
Comparar con una solución orientativa
Estado de pedido: base transaccional. Manuales: recuperación documental. Respuestas temporales reutilizables: caché con caducidad. No uses la caché como fuente definitiva de un dato cambiante.
3. Datos empresariales y modelos
Gobernar datos y elegir modelos son responsabilidades relacionadas pero diferentes. Un catálogo ayuda a encontrar y entender datos; un modelo procesa entradas.
- Redshift, S3 Tables, SageMaker Catalog, SageMaker Lakehouse y Lake Formation aparecen en la capa de datos empresariales y gobernanza. Deben revisarse sus funciones y compatibilidades concretas.
- Bedrock ofrece acceso gestionado a modelos fundacionales. SageMaker AI cubre flujos de construcción, entrenamiento y despliegue de modelos.
- El mapa menciona Amazon Nova 2, Hugging Face y modelos de terceros. Verifica el identificador, disponibilidad regional, licencia y precio antes de usarlos.
- No confundas acceder a un modelo por una API con entrenar uno propio. Comienza por un caso y una evaluación reproducible.
El proceso, en vertical
- Objetivo y datos permitidos
- Catálogo, procedencia y acceso
- Modelo candidato
- Evaluación de calidad, coste y latencia
- Selección documentada
Decide y comprueba
¿Qué debes comprobar antes de usar un modelo del mapa?
Ver razonamiento
La infografía no es una oferta de servicio ni una garantía de disponibilidad. El curso es gratuito; desplegar servicios puede tener coste.
Aplica lo aprendido
Escribe cuatro criterios para seleccionar un modelo de resumen.
Comparar con una solución orientativa
Fidelidad al documento, buen español, coste por documento y tiempo de respuesta. Añade privacidad y límites de entrada como requisitos, y prueba documentos largos, cortos y sin información relevante.
4. Orquestación de agentes y herramientas
La orquestación controla el recorrido de la tarea. Un servicio de ejecución, un framework y una pasarela de herramientas son piezas distintas.
- El mapa incluye Amazon Bedrock AgentCore, AgentCore Harness, Strands Agents, LangChain/LangGraph, LlamaIndex, Bedrock Flows y AgentCore Gateway.
- AgentCore agrupa capacidades gestionadas para ejecutar y operar agentes; Gateway conecta herramientas. Un framework define cómo se organiza la lógica de la aplicación.
- Un flujo fijo puede bastar para pasos conocidos. Usa decisiones de agente cuando las rutas dependan de resultados y puedan evaluarse.
- Define límites de intentos y permisos fuera del prompt. No publiques claves ni concedas acceso universal para simplificar el ejemplo.
El proceso, en vertical
- Solicitud y contrato de tarea
- Flujo o agente
- Herramienta autorizada
- Observación y evaluación
- Resultado o escalado
Decide y comprueba
¿Qué arquitectura usar para tres pasos siempre iguales?
Ver razonamiento
La elección empieza por la tarea. La complejidad debe aportar una mejora comprobable.
Aplica lo aprendido
Diseña un flujo que lea una solicitud, clasifique y prepare un borrador.
Comparar con una solución orientativa
Validar entrada, clasificar con categorías permitidas y generar borrador. Si falta información o la categoría no es clara, pedir revisión. El envío se mantiene separado y autorizado.
5. Observabilidad: ver qué ha pasado
Una aplicación necesita trazas para investigar errores y métricas para detectar degradación. Registrar todo sin criterio puede exponer información sensible.
- CloudWatch, CloudTrail y AgentCore Observability aparecen en el mapa. Distingue métricas y registros de aplicación de la auditoría de acciones en la cuenta.
- OpenTelemetry ofrece estándares e instrumentación para telemetría. OpenLLMetry es un proyecto orientado a instrumentación de aplicaciones de IA.
- Relaciona cada ejecución con versión, herramientas, duración y resultado. Evita introducir documentos privados completos en registros por defecto.
- Define alertas por errores, coste o latencia y un responsable de revisarlas. Tener un panel no implica que alguien atienda sus avisos.
El proceso, en vertical
- Identificador de ejecución
- Eventos y métricas mínimos
- Trazas de llamadas y errores
- Alerta con umbral
- Diagnóstico y corrección
Decide y comprueba
¿Qué registrarías para investigar un fallo sin copiar documentos enteros?
Ver razonamiento
La observabilidad debe ser útil y proporcionada. Los secretos no deben aparecer en trazas.
Aplica lo aprendido
Define una alerta accionable.
Comparar con una solución orientativa
Avisar si la tasa de errores supera un umbral durante una ventana y hay un mínimo de solicitudes. Incluir versión, operación y enlace a trazas filtradas, con una persona responsable y una acción de contención.
6. Evaluación, entrenamiento y operaciones de modelos
GenAIOps combina evaluación, versiones, despliegue y seguimiento. El rendimiento de una demo no basta para producción.
- El mapa agrupa Bedrock Evaluations, AgentCore Evaluations, Knowledge Bases y AWS Agent Registry. Consulta qué evalúa o registra cada componente; no son intercambiables.
- SageMaker AI, MLflow gestionado/serverless, HyperPod y Model Registry aparecen en entrenamiento y seguimiento del ciclo de vida.
- Evalúa respuesta, recuperación y acciones del agente por separado. Incluye casos sin respuesta, permisos insuficientes y herramientas caídas.
- Entrenar o ajustar un modelo no debe ser el primer reflejo ante cualquier fallo: puede faltar un documento, un filtro o una validación.
El proceso, en vertical
- Conjunto de casos de referencia
- Métricas y umbrales
- Versión candidata
- Evaluación comparativa
- Despliegue controlado y vigilancia
Decide y comprueba
Si el buscador no recupera el documento correcto, ¿qué revisas primero?
Ver razonamiento
Localiza el componente que falla antes de aumentar coste o complejidad.
Aplica lo aprendido
Diseña una evaluación de cinco casos.
Comparar con una solución orientativa
Dos preguntas respondibles, una sin respuesta, una con documento antiguo y una que intenta acceder a información no autorizada. Exige citas válidas, reconocimiento de límites y bloqueo de acceso.
7. CI/CD, desarrollo y proyecto final
El cambio de un prompt o de una herramienta también puede romper un sistema. Versiona configuración, código y pruebas junto a los modelos cuando corresponda.
- El mapa incluye GitHub, CloudFormation, CDK, CodeBuild, CodeDeploy y CodePipeline para control de versiones, infraestructura y entrega.
- Kiro, DevOps Agent y AWS Security Agent aparecen como herramientas de apoyo al desarrollo y operaciones. Su disponibilidad y alcance deben comprobarse antes de adoptarlas.
- Una entrega debe permitir probar, revisar y volver a una versión conocida. Un rollback de código no deshace necesariamente los efectos externos ya ejecutados.
- Proyecto final: un asistente interno con documentación ficticia, lectura acotada, evaluación y supervisión. Diseña primero; este curso no despliega infraestructura.
El proceso, en vertical
- Cambio versionado
- Pruebas automáticas y revisión
- Entorno de ensayo
- Despliegue controlado
- Seguimiento y plan de reversión
Decide y comprueba
¿Qué debe acompañar a una nueva versión?
Ver razonamiento
La entrega debe demostrar qué mejora y qué riesgos introduce, con evidencia y una forma de contener fallos.
Aplica lo aprendido
Propón una arquitectura mínima y un criterio de aprobación.
Comparar con una solución orientativa
Documentos ficticios en almacenamiento autorizado, índice compatible, modelo evaluado, interfaz y trazas mínimas. Aprobar solo si responde con fuentes válidas, reconoce ausencias y bloquea consultas fuera de permisos. Estimar costes antes de crear recursos.
Fuentes para profundizar
- AWS: Amazon Bedrock
- AWS: Amazon Bedrock AgentCore
- AWS: conceptos de Policy
- AWS: SageMaker AI
- AWS: IAM
- OpenTelemetry: conceptos
Edición: 4 de octubre de 2026. Comprueba la documentación vigente antes de elegir herramientas o desplegar un sistema. Completar este recurso no equivale a una certificación profesional.
Noticias, guías y recursos sobre inteligencia artificial en español. Responsable: Juan Andrés Balboa.
Conoce el proyecto y el criterio editorial · Comunicar una corrección
