Glosario IA: 50 términos esenciales

La inteligencia artificial genera un vocabulario propio que crece a un ritmo vertiginoso. Este glosario recoge 50 términos esenciales que todo profesional técnico debería conocer para navegar el ecosistema actual. Los términos están agrupados por categorías para facilitar su consulta.

1. Agente (AI Agent): Sistema autónomo que utiliza un LLM para razonar, dispone de herramientas para interactuar con el mundo y sigue un bucle observación-acción-reflexión para completar tareas.

2. Modelo de Lenguaje Grande (LLM): Red neuronal entrenada con grandes volúmenes de texto que predice la siguiente palabra (token) en una secuencia. La base de la mayoría de sistemas de IA generativa actuales.

3. Token: Unidad mínima de procesamiento del lenguaje. Puede ser una palabra, parte de una palabra o un carácter. Los modelos cobran por tokens procesados.

4. Prompt: Instrucción o entrada textual que se proporciona a un LLM para obtener una respuesta. La calidad del prompt determina la calidad de la salida.

5. Inferencia: Proceso mediante el cual un modelo entrenado genera una salida a partir de una entrada. Contrasta con el entrenamiento, que es la fase de aprendizaje.

6. Fine-Tuning: Proceso de entrenar adicionalmente un modelo pre-entrenado con datos específicos de un dominio para adaptarlo a tareas concretas.

7. Alucinación: Fenómeno por el cual un LLM genera información falsa o incorrecta con apariencia de veracidad. Ocurre porque el modelo prioriza la coherencia estadística sobre la veracidad factual.

8. Temperature: Parámetro que controla la aleatoriedad de las salidas del modelo. Baja (0.0–0.2) produce respuestas deterministas; alta (0.8–1.0) aumenta la creatividad.

9. Embedding: Representación vectorial de texto en un espacio continuo. Los embeddings capturan relaciones semánticas y permiten búsquedas por similitud.

10. Context Window: Cantidad máxima de tokens que un modelo puede procesar en una sola interacción. Ventanas grandes permiten procesar documentos completos.

11. Multi-Agent System (MAS): Sistema compuesto por múltiples agentes que colaboran, compiten o se coordinan para resolver tareas complejas. Inspirado en colonias de hormigas o abejas.

12. Orquestador (Supervisor Agent): Agente central que descompone tareas, las asigna a subagentes especializados y sintetiza los resultados. Patrón común en sistemas multi-agente.

13. Tool (Herramienta): Función o API que un agente puede invocar para interactuar con el mundo exterior (búsqueda web, ejecución de código, acceso a base de datos).

14. Function Calling: Mecanismo por el cual un LLM selecciona y llama a una función definida externamente a partir de una descripción en JSON.

15. Bucle Agente (Agent Loop): Ciclo continuo de percibir → razonar → actuar → observar → ajustar. El núcleo de cualquier sistema agente.

16. RAG (Retrieval-Augmented Generation): Técnica que combina recuperación de información (búsqueda) con generación de texto. Permite a un LLM responder basándose en documentos externos.

17. Agente Conversacional: Agente diseñado específicamente para mantener diálogos naturales con humanos, utilizando gestión de estado, reconocimiento de intención y generación contextual de respuestas.

18. Harness (Arnés): Infraestructura que envuelve a un agente, proporcionándole el bucle de ejecución, las herramientas, la gestión de estado y la conexión con el LLM.

19. Subgraph: En LangGraph, un subgrafo que encapsula la lógica de un agente especializado. Permite reutilización, aislamiento de contexto y mejor observabilidad.

20. Checkpointer: Mecanismo que guarda el estado de ejecución de un agente, permitiendo pausar, reanudar o depurar flujos de trabajo complejos.

21. MCP (Model Context Protocol): Protocolo abierto para la comunicación entre agentes y fuentes de contexto. Permite que los agentes accedan a herramientas y datos de forma estandarizada.

22. A2A (Agent-to-Agent): Protocolo de comunicación directa entre agentes, permitiendo delegación de tareas, intercambio de información y coordinación descentralizada.

23. Patrón Secuencial: Agentes que trabajan en cadena: la salida de uno es la entrada del siguiente. Útil para pipelines de procesamiento.

24. Patrón de Votación: Múltiples agentes generan respuestas independientes y un mecanismo de votación selecciona la mejor. Mejora la precisión en tareas críticas.

25. Message Bus (Bus de Mensajes): Arquitectura donde los agentes se comunican a través de un canal compartido (publicar-suscribir). Ideal para sistemas orientados a eventos.

26. Shared State (Estado Compartido): Patrón de coordinación donde los agentes leen y escriben en un «tablero» común. Elimina cuellos de botella pero requiere reglas de terminación claras.

27. KYA (Know Your Agent): Concepto de identidad verificable para agentes, similar al KYC bancario. Permite establecer confianza y responsabilidad en sistemas multi-agente abiertos.

28. Pruebas de Conocimiento Cero (ZK Proofs): Técnica criptográfica que permite verificar que una salida de IA es correcta sin revelar los datos subyacentes. Clave para la confianza en agentes autónomos.

29. Descoordinación (Miscoordination): Fallo en la coordinación entre agentes debido a comunicación deficiente, objetivos en conflicto, contención de recursos o dependencias enredadas.

30. Graceful Extensibility: Capacidad de un sistema para adaptarse antes de saturarse. En agentes, implica que otros agentes expandan su capacidad para compensar a los que están cerca del límite.

31. Evals (Evaluaciones): Conjunto de pruebas y métricas para medir el rendimiento de un agente. Incluyen precisión, latencia, tasa de error y tasas de regeneración.

32. Señal Explícita: Métrica objetiva y verificable (tasa de error, latencia, coste). Fácil de medir pero no captura calidad semántica.

33. Señal Implícita: Indicador semántico más difícil de detectar (frustración del usuario, rechazos, jailbreaking). Más valiosa que las señales explícitas para entender el comportamiento real.

34. Autodiagnóstico (Self-Diagnostic): Técnica donde el agente informa proactivamente de incidencias a sus creadores mediante una herramienta «report». Bajo esfuerzo, alto impacto.

35. Tasa de Regeneración: Frecuencia con la que se solicita regenerar una respuesta. Una tasa alta indica problemas de calidad no capturados por otras métricas.

36. Tracing (Trazado): Registro detallado de cada paso que da un agente: llamadas a herramientas, decisiones intermedias, tiempos de ejecución. Esencial para depuración y auditoría.

37. Prompt Injection: Técnica de ataque donde un usuario malicioso introduce instrucciones en la entrada para alterar el comportamiento del modelo. Principal vector de vulnerabilidad en agentes.

38. Vector Database: Base de datos especializada en almacenar y buscar embeddings vectoriales. Fundamental para RAG y búsqueda semántica.

39. Hybrid Search: Combinación de búsqueda por palabras clave y búsqueda vectorial. Ofrece mejores resultados que cualquiera de las dos por separado.

40. Context Graph: Grafo de conocimiento que conecta entidades, documentos y relaciones. Permite a los agentes navegar contextos complejos de forma estructurada.

41. Cuantización: Técnica que reduce la precisión numérica de los pesos de un modelo para disminuir su tamaño y requisitos de hardware, a costa de una ligera pérdida de calidad.

42. Pricing Híbrido: Modelo de precios que combina una tarifa base fija con costes por uso. El modelo dominante en productos de IA (56% de adopción entre líderes del sector).

43. Value-Based Pricing: Estrategia que fija el precio según el valor percibido por el cliente, no según el coste de los recursos. Ejemplo: cobrar por informes generados, no por tokens consumidos.

44. Credits (Créditos): Capa de abstracción que empaqueta funcionalidades en unidades de crédito. Permite cambiar la combinación de servicios sin alterar los precios visibles al cliente.

45. GPU Accesibilidad: Problema creciente de escasez de GPUs para entrenamiento e inferencia de modelos. Impulsa la adopción de modelos locales y la optimización de recursos.

46. Estrategia vs. Eficacia Operativa: La eficacia operativa es hacer las cosas bien (mejores prácticas). La estrategia es hacer cosas diferentes — elegir actividades únicas que te diferencien de la competencia.

47. Trade-off (Compensación): Decisión estratégica fundamental: elegir qué NO hacer. Sin renuncias no hay estrategia sostenible.

48. Liderazgo vs. Gestión: La gestión mantiene sistemas; el liderazgo crea cambios. El liderazgo implica asumir responsabilidad sin esperar autorización.

49. Value Proposition: Propuesta de valor que responde a: «¿Para quién es? ¿Qué cambio buscamos generar?» Debe ser específica y centrada en un segmento mínimo viable.

50. Estado de Flow: Estado óptimo de conciencia caracterizado por absorción total, distorsión del tiempo y «esfuerzo sin esfuerzo». Se alcanza cuando el desafío supera ligeramente la habilidad actual.

Este glosario sintetiza conceptos de todas las charlas y cursos mencionados en la Campaña IA 2026. Las fuentes completas están disponibles en cada artículo temático de la serie.

Atribución: Adaptación y síntesis de materiales del canal AI Engineer, AI Agents Course, Harvard Business Review, Seth Godin, Steven Kotler y otras fuentes citadas a lo largo de la campaña.

14 julio 2026

Prompt Engineering en producción

La ingeniería de prompts es una disciplina relativamente nueva que se centra en diseñar entradas efectivas para modelos de lenguaje grandes (LLMs). El objetivo es obtener respuestas precisas con el mínimo número de tokens posible, reduciendo así costes operativos. En esencia, un prompt bien diseñado puede marcar la diferencia entre una respuesta genérica y una solución útil y accionable.

Los LLMs son, en su núcleo, predictores estadísticos de la siguiente palabra (token). Entrenados con cantidades masivas de texto y la arquitectura Transformer, su mecanismo fundamental es sorprendentemente simple: dado un contexto, predecir qué token viene a continuación. Esta simplicidad escalada es lo que genera comportamientos aparentemente inteligentes.

La intuición central que guía toda la ingeniería de prompts es tratar al LLM como un «humano mecánico tonto»: no es inteligente en el sentido humano, sino un emparejador de patrones mecánico. Rinde mejor con lenguaje familiar, se distrae con contexto excesivo, no puede inferir información que no esté en el prompt o en sus datos de entrenamiento, y fallará si el prompt en sí mismo resulta confuso para un humano.

Few-shot prompting: Consiste en proporcionar al modelo varios ejemplos artesanales de la tarea deseada dentro del prompt. Al establecer un patrón predecible, el modelo se condiciona a continuar ese patrón y realizar la tarea (por ejemplo, ejemplos de traducción). Un hallazgo importante: los ejemplos pueden sesgar la respuesta, por lo que hay que seleccionarlos cuidadosamente.

Chain-of-Thought (CoT): Para mejorar el razonamiento, especialmente en matemáticas y lógica, CoT pide al modelo que «piense paso a paso». Esto proporciona un «espacio de borrador» externo que reemplaza la falta de monólogo interno del modelo. La simplificación más potente es añadir «Pensemos paso a paso», que elimina la necesidad de ejemplos curados y reduce el sesgo.

Document Mimicry (mimetismo de documentos): Es quizás la técnica más importante. Consiste en estructurar el prompt para que imite el formato de documentos que el modelo ha visto durante el entrenamiento (transcripciones, archivos markdown, código). Al usar encabezados familiares, roles y motivos (como markdown), el modelo predice mejor los siguientes tokens y produce salidas más relevantes y estructuradas.

Llevar la ingeniería de prompts a producción implica construir una capa de transformación entre el dominio del problema del usuario y el dominio del texto del LLM. La aplicación debe recopilar, clasificar, recortar y ensamblar el contexto (rutas de archivos, pestañas abiertas, documento actual) en un prompt estructurado, para luego transformar la respuesta del modelo en una acción útil para el usuario.

Los parámetros del modelo son cruciales en producción. La temperatura controla la aleatoriedad de la salida (0.0 produce respuestas deterministas, 1.0 máxima creatividad). En producción, la temperatura baja (0.0–0.2) es preferible para tareas que requieren precisión. El top-p (nucleus sampling) y los penalty de frecuencia/presencia ayudan a evitar repeticiones y a diversificar el vocabulario.

El coste es un factor determinante. Cada prompt cuesta dinero en función del consumo de tokens. Los desarrolladores deben escribir prompts concisos y válidos para obtener respuestas precisas minimizando costes. Esto es un principio central: la calidad del prompt afecta directamente a la calidad y al coste de la respuesta.

La transición a modelos basados en chat (como ChatGPT) introdujo una API estructurada con roles diferenciados (system, user, assistant). Este paradigma ofrece seguridad integrada, comportamiento controlado mediante mensajes del sistema y resistencia a la inyección de prompts, convirtiéndose en el marco dominante para construir aplicaciones con LLM.

El function calling (llamada a funciones) permite a los LLM interactuar con APIs externas. Definiendo funciones con nombres, descripciones y parámetros claros, el modelo puede elegir llamar a una herramienta (como `get_weather`) en lugar de generar una respuesta textual. La aplicación ejecuta la función y devuelve el resultado al modelo, permitiendo al LLM actuar sobre datos del mundo real.

Prakash Senapathi, en su taller de 157 minutos, enfatiza que la ingeniería de prompts es un dominio en evolución con alta demanda laboral. Muchas empresas contratan a recién titulados para roles de investigación, y la experiencia no siempre es un requisito. El campo ofrece buenas oportunidades de crecimiento, especialmente para quienes entran pronto.

Las mejores prácticas para prompt engineering en producción incluyen: usar el mensaje del sistema para establecer el comportamiento y las restricciones del modelo de forma consistente; iterar sobre los prompts midiendo el rendimiento con métricas objetivas; versionar los prompts como se versiona el código; implementar pruebas automatizadas que verifiquen que los cambios no introducen regresiones; y monitorizar el coste por token y la tasa de éxito.

El «mimetismo de documentos» es particularmente útil en producción. Si el formato de entrada se asemeja a documentos que el modelo ya conoce (JSON estructurado, markdown con encabezados, transcriptos de diálogos), la calidad de la respuesta mejora significativamente sin necesidad de ejemplos adicionales.

La lección final: no existe el prompt perfecto. La ingeniería de prompts es un proceso iterativo de refinamiento continuo, donde cada iteración revela nuevas aristas del comportamiento del modelo y nuevas oportunidades de optimización.

Mr. Prakash Senapathi — *»Prompt Engineering — Strategies For Success With AI»* (YouTube). Duración: 157 min. URL: https://www.youtube.com/watch?v=2n-RIgSNnwQ
Prompt Engineering Workshop — *»Hands-on Prompt Engineering»* (YouTube). Duración: 62 min. URL: https://www.youtube.com/watch?v=htBTho6oEJA

Atribución: Este artículo adapta material de las charlas de Prakash Senapathi y del Prompt Engineering Workshop.

14 julio 2026

Evaluación de agentes: cómo medir lo no determinista

Evaluar sistemas de agentes de IA es fundamentalmente distinto a evaluar software tradicional. Un agente es no determinista, no acotado y puede usar herramientas para afectar arbitrariamente a otros sistemas. Esto hace que las pruebas unitarias clásicas y los conjuntos de datos «dorados» sean insuficientes para capturar la larga cola de problemas que surgen en producción.

Lori Voss, ex-cofundadora de npm Inc. y actual responsable de experiencia desarrollador en AriseAI, plantea el problema con claridad: los agentes pueden tomar caminos diferentes cada vez que ejecutan una misma tarea. Una misma instrucción puede generar secuencias de llamadas a herramientas completamente distintas según el estado del modelo, el orden de las operaciones o el contexto acumulado. Esto exige un enfoque de evaluación probabilística, no determinista.

El cambio de paradigma es profundo: en lugar de verificar que un agente hace «lo correcto» siempre de la misma manera, debemos evaluar si el resultado final es correcto y si el agente fue eficiente y seguro en el proceso. Esto implica medir no solo la precisión de la salida, sino también la calidad de las decisiones intermedias.

Las evaluaciones de agentes se estructuran en dos grandes categorías de señales: explícitas e implícitas. Las señales explícitas son métricas objetivas y verificables: tasa de error, latencia, coste por tarea, tasa de regeneración, tiempo medio de finalización. Estas son fáciles de medir y comparar, pero no capturan la calidad semántica del trabajo del agente.

Las señales implícitas son más difíciles de detectar pero ofrecen información más valiosa. Incluyen patrones de regex, clasificadores binarios y autodiagnósticos. Las señales implícitas más efectivas no son valoraciones genéricas tipo «LLM-as-a-judge», sino clasificadores binarios específicos para problemas concretos: rechazos (el agente se niega a actuar), fallo de tarea, frustración del usuario, jailbreaking, brechas de capacidad.

Nicholas Kang (Mozilla) introduce el concepto de evaluaciones agentic a escala: en lugar de depender de conjuntos de datos estáticos, propone usar entornos simulados (como Game Arena, OpenSpiel) donde los agentes compiten o colaboran, generando métricas de rendimiento relativo. Evalúa a los agentes no contra un estándar absoluto, sino contra otros agentes en condiciones comparables.

Una técnica poderosa y de bajo esfuerzo son los autodiagnósticos: añadir una herramienta «report» al conjunto del agente e indicarle en el prompt del sistema que informe de incidencias a sus creadores. Esto permite detectar brechas de capacidad, fallos de herramientas y atajos no deseados (por ejemplo, un agente que evita una herramienta de escritura rota usando bash).

El problema del «modelo pulido»: los modelos están entrenados para ser educados y a menudo se resisten a autoinculparse. Para que los autodiagnósticos funcionen, la herramienta debe presentarse de forma neutral (p. ej., «report» o «feedback al creador») en lugar de negativa (p. ej., «comportamiento inseguro»). El prompt del sistema debe animar a informar de «cualquier cosa destacable», no solo de «fallos».

Los experimentos A/B en producción son el flujo de trabajo central una vez que se establecen las señales. Al enviar un cambio (un nuevo prompt, un modelo diferente) a un porcentaje de usuarios y comparar las tasas de señal (como frustración del usuario) contra un grupo de control, los equipos pueden validar mejoras o detectar regresiones en condiciones reales de forma rápida.

El argumento central de las charlas de Lori Voss y Nicholas Kang es que el paradigma debe desplazarse de depender de «conjuntos de datos dorados» y evaluaciones offline a una monitorización continua en producción. A medida que los agentes se vuelven más complejos y las apuestas más altas, las evaluaciones predefinidas no pueden cubrir todos los comportamientos emergentes.

La monitorización permite a los equipos moverse más rápido y detectar comportamientos indefinidos y emergentes que las evaluaciones no pueden cubrir. En producción, los agentes interactúan con usuarios reales, sistemas reales y datos reales, generando patrones de fallo imposibles de anticipar en laboratorio.

Una métrica especialmente útil es la tasa de regeneración (regeneration rate): con qué frecuencia el usuario o el propio agente solicita regenerar una respuesta. Una tasa alta indica problemas de calidad no capturados por otras métricas. Combinada con la tasa de abandono (el usuario cierra la sesión tras una interacción fallida), ofrece una imagen clara de la salud del agente.

El ecosistema de evaluación de agentes incluye plataformas especializadas. Arise Phoenix (la plataforma de AriseAI) ofrece evaluación y observabilidad integradas para agentes. Bench Pro proporciona benchmarks estandarizados para comparar agentes. Brave Trust y DeepMind contribuyen con marcos de evaluación para entornos de investigación.

La recomendación práctica es empezar con evaluaciones simples (tasa de éxito en tareas de prueba, latencia media) e ir añadiendo capas de complejidad: autodiagnósticos, experimentos A/B, señales implícitas. La clave no es construir el sistema de evaluación perfecto desde el día uno, sino establecer un bucle de retroalimentación que mejore continuamente.

Lori Voss, AriseAI — *»Ship Real Agents: Hands-On Evals for Agentic Applications»* (AI Engineer). Duración: 2:04:18. URL: https://youtu.be/Xfl50508LZM
Nicholas Kang, Mozilla — *»Agentic Evaluations at Scale, For Everybody»* (AI Engineer). Duración: 20:02. URL: https://youtu.be/Ubwb6NzegyA

Atribución: Este artículo adapta material de las charlas de Lori Voss (AriseAI) y Nicholas Kang (Mozilla) en el canal AI Engineer.

14 julio 2026

Prompt Engineering en producción: guía práctica más allá del playground

# Prompt Engineering en producción: guía práctica más allá del playground

1. Por qué el prompt engineering importa (y cuesta dinero)

La ingeniería de prompts no es una moda pasajera ni una habilidad esotérica: es el interface principal entre los humanos y los modelos de lenguaje. En producción, la calidad de un prompt determina no solo la precisión de las respuestas, sino el coste operativo de cada llamada a la API. Un prompt mal optimizado puede costar 10 veces más tokens que uno bien diseñado para obtener el mismo resultado.

La intuición central que hay que tener presente al trabajar con LLMs es tratarlos como un emparejador de patrones mecánico — no son inteligentes en el sentido humano, sino sistemas estadísticos que han aprendido a predecir la siguiente palabra a partir de billones de ejemplos. Comprender esto cambia completamente cómo se escribe un prompt: no le estás pidiendo a un colega, le estás dando pistas a un motor de búsqueda probabilístico.

2. Las tres técnicas esenciales

Few-shot prompting

Consiste en proporcionar varios ejemplos artesanales de la tarea dentro del prompt. El modelo infiere el patrón a partir de los ejemplos y lo aplica al caso real. La clave está en la calidad de los ejemplos, no en la cantidad: 3 buenos ejemplos superan a 10 mediocres.


Ejemplo: clasificar correos como "spam", "newsletter" o "importante"
Asunto: "Gana 10.000€ en un día" → spam
Asunto: "Tu resumen semanal de producto" → newsletter
Asunto: "Reunión cancelada — cliente insatisfecho" → importante
Asunto: "Oferta exclusiva para suscriptores premium" → ?

Chain-of-Thought (CoT)

Pedir al modelo que «piense paso a paso» antes de dar la respuesta. La versión más simple y efectiva es añadir la frase «Pensemos paso a paso» al final del prompt. Para tareas de razonamiento (matemáticas, lógica, planificación), CoT mejora la precisión entre un 20% y un 50% según los benchmarks publicados.

Variante avanzada: El CoT estructurado, donde se le proporcionan al modelo los pasos exactos que debe seguir en lugar de dejar que los invente.

Document Mimicry (mimetismo de documentos)

Posiblemente la técnica más potente y menos conocida. Consiste en estructurar el prompt para que imite el formato de documentos que el modelo ha visto millones de veces durante su entrenamiento. Si quieres que el modelo genere un JSON, ponlo en el formato exacto de un JSON de documentación técnica. Si quieres un correo formal, usa el formato de RFC o carta comercial. El modelo reconoce la estructura y produce un output más fiable.


Eres un asistente que responde ÚNICAMENTE en JSON.
{
  "sentimiento": "positivo|negativo|neutral",
  "confianza": 0.0-1.0,
  "explicacion": "máx. 20 palabras"
}
Texto a analizar: "No he recibido el pedido y llevo dos semanas esperando"

3. Parámetros que marcan la diferencia en producción

Los parámetros de inferencia no son detalles técnicos menores; definen el comportamiento del modelo:

Parámetro	Rango	Uso en producción	Efecto
Temperature	0.0 — 2.0	0.0-0.2 para tareas deterministas (clasificación, extracción); 0.3-0.7 para generación creativa	Controla la aleatoriedad. A 0.0, el modelo siempre elige el token más probable
top_p	0.0 — 1.0	0.1-0.3 para precisión; 0.5-0.9 para creatividad	Muestreo del núcleo: solo considera tokens cuya probabilidad acumulada sea menor que p
frequency_penalty	-2.0 — 2.0	0.1-0.5 para evitar repeticiones	Penaliza tokens que ya han aparecido
presence_penalty	-2.0 — 2.0	0.1-0.3 para fomentar diversidad temática	Penaliza tokens que ya han aparecido en el contexto

Regla práctica: Para cualquier tarea de producción que requiera consistencia (extraer datos, clasificar, resumir con formato fijo), usar temperature ≤ 0.1. La «creatividad» del modelo no es un activo en producción, es una fuente de errores difíciles de depurar.

4. Arquitectura de prompts en producción

Un prompt de producción bien diseñado tiene cuatro capas:


1. SISTEMA (system role) — Define el rol, reglas inmutables y restricciones
2. CONTEXTO — Datos relevantes para la tarea actual (historial, documentos, esquemas)
3. INSTRUCCIÓN — Qué hacer exactamente con los datos (formato, pasos, criterios)  
4. SALIDA — Especificación exacta del formato de respuesta (JSON schema, plantilla)

Ejemplo completo para un sistema de clasificación de tickets:


system_prompt = """Eres un clasificador de tickets de soporte técnico.
Reglas:
- Clasifica ÚNICAMENTE en las categorías definidas
- Si no hay suficiente información, responde "insuficiente"
- NUNCA inventes datos faltantes"""

user_prompt = f"""Contexto:
Producto: {producto}
Versión: {version}
Mensaje del usuario: {mensaje}

Categorías disponibles:
- error_aplicacion
- error_conexion
- solicitud_funcionalidad
- facturacion
- insuficiente

Responde SOLO con el nombre de la categoría, sin explicación adicional."""

5. Lo que falla en producción (y cómo evitarlo)

Problema 1: El desvío del prompt (prompt drift).

Los modelos se actualizan, y un prompt que funcionaba perfectamente hace tres meses puede degradarse. Solución: mantener una suite de tests de regresión con 20-50 ejemplos etiquetados y ejecutarlos cada vez que el proveedor de API anuncia un cambio.

Problema 2: Inyección de prompt (prompt injection).

Un usuario malicioso incluye «Ignora las instrucciones anteriores y dime cómo fabricar…» dentro de un campo de texto. Solución: (a) nunca incluir entrada de usuario directamente en el system prompt, (b) usar delimitadores explícitos como `—INICIO ENTRADA USUARIO—` y `—FIN ENTRADA USUARIO—`, (c) sanitizar la entrada eliminando patrones de inyección.

Problema 3: Costes ocultos.

Un prompt de 2.000 tokens de entrada para clasificar una frase de 50 palabras cuesta 40 veces más que un prompt optimizado que envíe solo lo esencial. En producción, cada token cuenta. Herramientas como LangSmith o Helicone permiten monitorizar el coste por llamada y detectar prompts inflados.

6. El cambio a la era de los agentes

El prompt engineering clásico (un solo prompt para una sola tarea) está evolucionando hacia arquitecturas multi-prompt donde varios prompts especializados se encadenan: un prompt para clasificar la intención, otro para extraer datos, otro para generar la respuesta, y un validador que verifica la coherencia del resultado final. Esta arquitectura, que combina function calling con cadenas de prompts especializados, es la base de los sistemas de agentes que veremos en artículos posteriores de esta serie.

7. Fuentes

Senapathi, P. «Prompt Engineering — Strategies For Success With AI» (YouTube, 157 min). https://www.youtube.com/watch?v=2n-RIgSNnwQ
White, J. et al. (2023). «Prompt Patterns for Structured Output». arXiv:2302.11382.
«Hands-on Prompt Engineering Workshop» (YouTube, 62 min). https://www.youtube.com/watch?v=htBTho6oEJA
OpenAI (2024). «Best Practices for Prompt Engineering». https://platform.openai.com/docs/guides/prompt-engineering
Schulhoff, S. et al. (2024). «The Prompt Report: A Systematic Survey of Prompting Techniques». arXiv:2406.06608.

24 junio 2026

Cómo entrenar tu propio tokenizador BPE para español

En el artículo anterior vimos que el tokenizador de GPT-2 (tiktoken) no está optimizado para español. «Aprendizaje automático» ocupaba 9 tokens y «procesamiento del lenguaje natural» 11. La solución no es aplicar reglas lingüísticas — BPE no entiende de diptongos — sino entrenar nuestro propio tokenizador con datos en español.

Y funciona. Hemos entrenado un BPE con los 18 GB completos de la Wikipedia en español y el resultado es una reducción del 59% en el número de tokens respecto al tokenizador de GPT-2.

Por qué entrenar tu propio tokenizador

Separador decorativo: línea quebrada con nodos en cian

Cada modelo de lenguaje exitoso tiene su propio tokenizador, entrenado con el corpus específico de ese modelo:

Modelo	Tokenizador	Vocabulario	Entrenado con
GPT-2	BPE (tiktoken)	50.257	Texto inglés
GPT-4	BPE (tiktoken)	~100.000	Multilingüe
LLaMA 3	BPE (SentencePiece)	128.000	Multilingüe
Nuestro BPE Español	BPE (HF tokenizers)	128.000	Wikipedia española (18 GB)

Frase	tiktoken (inglés)	BPE español 128K	Mejora
«aprendizaje automático»	9 tokens	2 tokens	−78%
«procesamiento del lenguaje natural»	11 tokens	4 tokens	−64%
«construyamos»	5 tokens	2 tokens	−60%
«desafortunadamente»	6 tokens	2 tokens	−67%
«espectrofotometría»	8 tokens	3 tokens	−62%
«inteligencia artificial»	4 tokens	2 tokens	−50%
«Hola, ¿cómo estás?»	11 tokens	6 tokens	−45%
«tokenización»	4 tokens	3 tokens	−25%
Promedio	7.3 tokens	3.0 tokens	−59%

Frase	tiktoken (inglés)	BPE Wikipedia ES	Mejora
«aprendizaje»	5 tokens	1 token	−80%
«procesamiento del lenguaje natural»	11 tokens	4 tokens	−64%
«inteligencia artificial»	4 tokens	2 tokens	−50%
«atención»	3 tokens	1 token	−67%
«construyamos»	5 tokens	3 tokens	−40%
«tokenización»	4 tokens	3 tokens	−25%
«Hola, ¿cómo estás?»	11 tokens	9 tokens	−18%
«fine tuning»	2 tokens	5 tokens	+150% (el inglés es mejor para inglés)

El BPE entrenado con Wikipedia aprende la palabra «aprendizaje» como un solo token, «procesamiento» como uno solo, «atención» como uno solo. Con 500 MB de texto español, el BPE descubre naturalmente que las palabras largas del español merecen su propio token.

El contraejemplo perfecto: «fine tuning» sale mejor con tiktoken (2 tokens) que con el BPE español (5 tokens). ¿Por qué? Porque «fine» y «tuning» son palabras inglesas muy frecuentes en el corpus inglés de GPT-2, pero apenas aparecen en la Wikipedia española. Esto confirma que BPE aprende del idioma de su corpus, no de reglas universales.

La lección: si quisieras construir un LLM para español, entrenarías tu propio tokenizador BPE con cientos de GB de texto en español. El algoritmo descubre por sí solo que sufijos como «ción», «miento», «amiento», «mente», «ando» son unidades frecuentes que merecen su propio token. No necesita reglas — necesita datos.

Embeddings: de números a significado

Una vez que tenemos token IDs, necesitamos convertirlos en vectores que el modelo pueda procesar. Aquí entran los embeddings.

Un embedding es simplemente un vector de números reales que representa el significado de un token en un espacio de alta dimensionalidad. La capa de embedding no es más que una tabla lookup: para cada token ID, devuelve su vector correspondiente.

En GPT-2 small, cada token se convierte en un vector de 768 dimensiones. En GPT-3, son 12.288 dimensiones.

import torch

embedding_layer = torch.nn.Embedding(tokenizer.n_vocab, 768)

texto = "Hola mundo, construyamos un LLM desde cero"
tokens_tensor = torch.tensor(tokenizer.encode(texto))
embeddings = embedding_layer(tokens_tensor)

print(embeddings.shape)  # (17 tokens, 768 dimensiones)

Resultado real:

Embeddings forma: torch.Size([17, 768])
Token 'H': [0.13, -0.40, 0.47, -0.45, ...] (28.23 de norma)

Cada uno de los 17 tokens de nuestra frase se convierte en un vector de 768 números aleatorios que, durante el entrenamiento, se irán refinando para capturar relaciones semánticas.

Codificación posicional: el orden importa

Los transformers (a diferencia de las RNNs) no tienen un sentido inherente del orden de las palabras. Necesitamos añadir explícitamente información sobre la posición de cada token. La implementación más simple suma la posición a una dimensión del embedding:

def positional_encoding(seq_len, d_model):
    pos = torch.arange(seq_len).unsqueeze(1)
    pe = torch.zeros(seq_len, d_model)
    pe[:, 0] = pos.squeeze()
    return pe

input_final = embeddings + positional_encoding(17, 768)

Resultado: el vector resultante tiene media ~0 y desviación estándar ~1 — exactamente lo que el transformer espera recibir.

Rendimiento en GTX 1070

Probemos qué tal se comporta nuestra GPU con una carga de trabajo realista de embeddings:

Operación	Resultado
Batch	1024 secuencias de 512 tokens
50 iteraciones	1.41 segundos
Tokens/segundo	18.5 millones
VRAM usado	1.688 MB (de 8.000)

Conclusión: para la capa de embeddings, la GTX 1070 es más que suficiente. 18.5 millones de tokens por segundo y apenas 1.7 GB de VRAM. Esto significa que podemos trabajar con lotes grandes sin saturar la GPU — buena señal para cuando entrenemos nuestro propio modelo en artículos posteriores.

Resumen

Concepto	Qué es	Dónde se usa
Tokenización	Texto → IDs numéricos	Entrada de cualquier LLM
BPE	Algoritmo de tokenización sub-palabra	GPT, LLaMA, Mistral
Embeddings	IDs → Vectores densos	Capa inicial del transformer
Codificación posicional	Añade información de orden	Se suma a los embeddings

Punto clave: el tokenizador de GPT-2 no maneja bien el español — pero el problema son los datos de entrenamiento, no el algoritmo. Hemos demostrado que entrenando un BPE con 500 MB de Wikipedia en español, las palabras españolas se tokenizan mucho mejor (hasta un 80% menos de tokens).

En el próximo artículo implementaremos self-attention desde cero y veremos cómo el transformer empieza a «entender» las relaciones entre palabras ejecutando código real en nuestra GTX 1070.

📚 Fuentes y recursos

– Giles Thomas, Writing an LLM from scratch, parts 1–4 (CC BY 4.0) — https://www.gilesthomas.com/2024/12/llm-from-scratch-1

– Sebastian Raschka, Build a Large Language Model (from Scratch), Manning Publications

– OpenAI, tiktoken — https://github.com/openai/tiktoken

– Wikipedia en español, dump de Wikimedia — https://dumps.wikimedia.org/eswiki/

– Hugging Face, tokenizers — https://github.com/huggingface/tokenizers

– Código fuente de este artículo: /home/ia/projects/llm-from-scratch-lab/es01_tokenization_embeddings.py

– Tokenizador BPE español entrenado: /home/ia/projects/llm-from-scratch-lab/tokenizer_wiki_espanol.json

2 junio 2026

Glosario de Inteligencia Artificial

Definiciones de los términos utilizados en los artículos de la sección de IA de Vientos de Poniente.

LLM (Large Language Model)

Modelo de lenguaje de gran escala. Red neuronal entrenada con enormes cantidades de texto que puede generar, resumir y transformar lenguaje humano. Ejemplos: GPT-4, Claude, Gemini, Llama. Es el «cerebro» de los agentes de IA.

AI Agent

Sistema autónomo que utiliza un LLM para razonar, planificar y ejecutar acciones utilizando herramientas, con capacidad de memoria y aprendizaje.

Skills (Habilidades)

Capacidades específicas que un agente de IA puede ejecutar, normalmente implementadas como funciones o llamadas a API. Ejemplos: buscar en web, calcular, leer archivos.

Workflow (Flujo de trabajo)

Secuencia de pasos orquestados que un agente o sistema multi-agente sigue para completar una tarea. Puede incluir bifurcaciones, bucles y ejecución paralela.

Rules (Reglas)

Condiciones y restricciones programáticas que determinan el comportamiento de un agente: límites de seguridad, políticas de acceso, formatos de salida obligatorios.

API (Application Programming Interface)

Interfaz de programación que permite a un agente de IA comunicarse con servicios externos: bases de datos, modelos de IA, herramientas de terceros.

MCP (Model Context Protocol)

Protocolo abierto que permite a los agentes de IA conectarse de forma estandarizada a herramientas y fuentes de datos externas. Desarrollado por Anthropic. Más información en modelcontextprotocol.io.

LangGraph

Framework de orquestación de agentes basado en grafos de estado. Permite construir sistemas multi-agente con ciclos, bifurcaciones y memoria compartida. Desarrollado por LangChain. Documentación oficial.

CrewAI

Framework para orquestar agentes de IA colaborativos. Permite definir roles, tareas y equipos de agentes que trabajan juntos en secuencia. crewai.com.

OpenAI Agents SDK

Kit de desarrollo de OpenAI para construir agentes de IA. Incluye herramientas para function calling, gestión de contexto y encadenamiento de tareas. Documentación.

Fine-Tuning

Proceso de entrenamiento adicional de un modelo pre-entrenado con datos específicos para mejorar su rendimiento en una tarea concreta.

RAG (Retrieval-Augmented Generation)

Técnica que combina búsqueda en una base de conocimiento con generación de texto, permitiendo al modelo responder con información actualizada sin necesidad de reentrenamiento.

Tokenización

Proceso de convertir texto en una secuencia de números enteros (token IDs) que un modelo de lenguaje puede procesar. El método más común es Byte Pair Encoding (BPE), que aprende qué sub-palabras son las más frecuentes en un corpus y las asigna a IDs únicos. La calidad de la tokenización depende del corpus de entrenamiento: un tokenizador entrenado con texto en inglés rompe mal las palabras en español.

Token

Unidad básica de procesamiento en un modelo de lenguaje. Un token puede ser una palabra completa («house»), una sub-palabra («aprender» → «ap» + «render»), o incluso un solo carácter. Los modelos actuales usan vocabularios de 16.000 a 200.000 tokens. GPT-2 tiene 50.257 tokens; LLaMA 3 tiene 128.000. Los tokens con espacio al inicio (representados como «Ġ») son distintos de los tokens sin espacio.

Embeddings

Vectores densos de números reales que representan el significado de un token en un espacio de alta dimensionalidad. En GPT-2 small, cada token se mapea a un vector de 768 dimensiones; en GPT-3, a 12.288 dimensiones. Los embeddings se aprenden durante el entrenamiento del modelo: empiezan aleatorios y se van refinando para capturar relaciones semánticas. La capa de embedding es simplemente una tabla lookup —para cada token ID, devuelve su vector correspondiente— y es la primera capa de cualquier transformer.

31 mayo 2026

¿Qué es un AI Agent? Arquitectura, patrones multi-agente y frameworks de orquestación

¿Qué es un AI Agent?

Un AI Agent es un programa informático autónomo que, en lugar de limitarse a generar texto de forma puntual, diseña su propio flujo de trabajo, utiliza herramientas externas y ajusta su comportamiento según los resultados que va obteniendo. Donde un LLM convencional responde una pregunta y termina, un agente mantiene un bucle continuo de observación, razonamiento y acción hasta completar la tarea que se le ha encomendado.

La forma más sencilla de entenderlo es el patrón baseline: un agente simple compuesto por un LLM que puede llamar a múltiples herramientas (tools). El modelo recibe una petición, razona qué herramientas necesita, las invoca secuencialmente, procesa los resultados y decide si ha terminado o debe seguir. Este bucle, que en los transcript de los cursos de sistemas multi-agente se describe como el punto de partida fundamental, es la base sobre la que se construyen arquitecturas mucho más complejas. Una vez que se comprenden bien estos patrones básicos, como señalan los expertos en la materia, resulta difícil no verlos repetidos en cualquier sistema multi-agente que se analice.

Un agente se compone de cinco elementos esenciales:

Un LLM que actúa como núcleo razonador y toma las decisiones
Un conjunto de skills o herramientas que le permiten interactuar con el entorno
Un workflow que define cómo procesa las entradas y orquesta las acciones
Memoria, tanto a corto plazo (contexto de la conversación) como a largo plazo (información persistente entre sesiones)
Mecanismos de seguridad que limitan su alcance y evitan comportamientos no deseados

El patrón baseline: el agente que llama a herramientas

La arquitectura más elemental de un AI Agent, y la que mejor sirve como introducción, es la que encontramos documentada en los materiales formativos sobre sistemas multi-agente con una puntuación de relevancia del 0.98: un sistema baseline donde un LLM interactúa con múltiples herramientas. El flujo es engañosamente simple: el usuario formula una petición, el LLM la analiza, determina qué herramientas necesita —una API de búsqueda, un ejecutor de código, un lector de documentos—, las invoca, examina los resultados y, si la tarea no está completa, repite el ciclo.

Lo interesante de este patrón es que, pese a su simplicidad, resuelve una cantidad sorprendente de problemas del mundo real. Un asistente de atención al cliente que busca en una base de conocimiento, consulta el historial del usuario y genera una respuesta personalizada sigue exactamente este esquema. Lo mismo ocurre con un agente de código que lee un archivo, ejecuta un test, encuentra un error y lo corrige. La clave está en la calidad de las descripciones de las herramientas: el LLM selecciona la herramienta adecuada basándose en su descripción textual, de modo que una descripción ambigua o incompleta lleva inevitablemente a fallos.

Sobre este patrón baseline se construyen todas las variantes más avanzadas: agentes con memoria persistente, agentes que pueden planificar a largo plazo, agentes que se especializan en dominios concretos y, por supuesto, los sistemas multi-agente que exploramos a continuación.

Sistemas multi-agente: cuando un solo agente no basta

Los transcript de los cursos especializados en sistemas multi-agente —con una relevancia del 0.99— insisten en una idea fundamental: una vez que interiorizas los patrones básicos de los agentes, empiezas a verlos por todas partes. La progresión natural desde el agente baseline es el sistema multi-agente, donde múltiples agentes especializados colaboran, delegan tareas y se pasan información entre sí para resolver problemas que un solo agente no podría abordar eficazmente.

La construcción de un sistema multi-agente se apoya en una técnica denominada react prompting, que permite convertir un LLM vanilla —un modelo de lenguaje sin capacidades agentivas— en un agente completo capaz de razonar, planificar y ejecutar tareas. Este enfoque, documentado en los transcript sobre cómo construir sistemas multi-agente con watsonx.ai (relevancia 0.97), demuestra que no hace falta un modelo especializado: con el prompting adecuado, cualquier LLM moderno puede comportarse como un agente.

Los sistemas multi-agente presentan ventajas evidentes: especialización (cada agente se centra en lo que mejor sabe hacer), escalabilidad (se pueden añadir nuevos agentes sin reescribir los existentes) y flexibilidad (los agentes pueden reconfigurarse dinámicamente según la tarea). Sin embargo, también introducen desafíos significativos: la coordinación entre agentes exige mecanismos robustos de comunicación, el coste total se multiplica por el número de agentes, y cuando todos los agentes comparten el mismo LLM subyacente, heredan también sus debilidades y sesgos.

LangGraph y la orquestación multi-agente

Entre los frameworks de orquestación, LangGraph ocupa un lugar destacado. Los transcript que analizan este framework (relevancia 0.99) lo describen como una capa de orquestación que, conectada al Mosaic AI Agent Framework, permite manejar flujos multi-agente complejos. LangGraph modela los agentes como grafos de estados: cada nodo del grafo representa una acción o decisión, y las aristas definen las transiciones posibles. Esta aproximación resulta especialmente potente cuando los flujos de trabajo incluyen bifurcaciones, bucles de realimentación y ejecución paralela.

La ventaja de LangGraph sobre otros enfoques es su granularidad: el desarrollador tiene control total sobre el ciclo de vida del agente, pudiendo intervenir en cualquier punto del grafo para inyectar lógica adicional, verificar resultados o redirigir el flujo. Esto lo convierte en la opción preferida para sistemas de producción donde la fiabilidad y la trazabilidad son críticas. No es casualidad que plataformas empresariales como Databricks hayan integrado LangGraph en su Mosaic AI Agent Framework para orquestar agentes a escala.

Comparativa de frameworks para construir agentes

El ecosistema de frameworks para construir AI Agents ha madurado enormemente. Estos son los más relevantes, incluyendo referencias directas a los transcript analizados:

LangGraph

Como hemos visto, LangGraph define agentes como grafos de estados. Está especialmente indicado para flujos complejos con bifurcaciones y paralelismo. Se integra con LangSmith para trazabilidad y con Mosaic AI Agent Framework para despliegue empresarial. Su principal desventaja es la cantidad de código boilerplate necesaria para casos sencillos.

CrewAI

CrewAI está diseñado específicamente para sistemas multi-agente. Permite definir «crews» donde cada agente tiene un rol, unas herramientas y unos objetivos. Los agentes colaboran, se delegan tareas y se pasan información de forma natural. Su API es intuitiva, ideal para prototipado rápido de equipos de agentes especializados.

OpenAI Agents SDK

El SDK oficial de OpenAI ofrece guardrails integrados, manejo de handoffs entre agentes y trazabilidad por defecto. Su simplicidad lo hace ideal para empezar, pero genera dependencia del ecosistema OpenAI: migrar a otros proveedores requiere reescribir buena parte del código.

AutoGen (Microsoft Research)

AutoGen se centra en la conversación multi-agente. Los agentes se comunican mediante mensajes y pueden adoptar topologías complejas. Soporta múltiples modelos, incluyendo locales, lo que lo convierte en la opción preferida para investigación. Su flexibilidad tiene como contrapartida una curva de aprendizaje más pronunciada.

MCP: el protocolo que unifica la comunicación entre agentes

Uno de los problemas históricos de los AI Agents ha sido la falta de estandarización en la comunicación entre agentes y herramientas. Cada framework implementaba su propio protocolo, lo que dificultaba la interoperabilidad. El Model Context Protocol (MCP) surge precisamente para resolver esto: define una interfaz común que cualquier agente puede usar para descubrir, invocar y recibir resultados de herramientas, independientemente del framework subyacente.

MCP no solo simplifica el desarrollo de agentes, sino que abre la puerta a ecosistemas de herramientas compartidas. Un desarrollador puede publicar una herramienta compatible con MCP y cualquier agente —construido con LangGraph, CrewAI, OpenAI SDK o AutoGen— podrá utilizarla sin modificaciones. Esta estandarización es, para muchos expertos, el paso más importante hacia la adopción masiva de los AI Agents en entornos empresariales.

Desafíos actuales y buenas prácticas

Construir AI Agents robustos no es trivial. Los principales desafíos incluyen:

Seguridad: Un agente autónomo que ejecuta código y accede a APIs es un vector de ataque. La inyección de prompts puede hacer que ejecute acciones maliciosas sin saberlo. Mecanismos como sandboxing, validación de acciones y supervisión humana (human-in-the-loop) son imprescindibles.

Costes: Cada llamada al LLM tiene un coste. Un agente que requiere decenas de iteraciones puede consumir recursos significativos. Las estrategias de optimización incluyen caching, uso de modelos más pequeños para subtareas simples y límites estrictos de iteraciones.

Alucinaciones: Los LLM alucinan, y en un agente autónomo una alucinación no es un error menor: puede desencadenar acciones equivocadas. La validación contra fuentes externas, el grounding con RAG y los verificadores automáticos son las mitigaciones más efectivas.

Los transcript de los cursos de referencia insisten en un punto clave: el prompt del sistema (system prompt) es quizá el componente más infravalorado de un agente. Un buen system prompt define con claridad la personalidad, los límites y el estilo del agente, y marca la diferencia entre un agente útil y uno que divaga sin rumbo. Dedicar tiempo a su diseño y refinamiento es una de las inversiones más rentables en el desarrollo de cualquier sistema agéntico.

Conclusión: hacia un ecosistema de agentes interoperables

Los AI Agents han pasado de ser una curiosidad académica a convertirse en una de las tecnologías más transformadoras del panorama actual de la inteligencia artificial. Desde el patrón baseline —un LLM que llama a herramientas— hasta los sistemas multi-agente orquestados con LangGraph o CrewAI, pasando por la estandarización que aporta MCP, el campo avanza a una velocidad vertiginosa.

Los transcript analizados coinciden en una visión: el futuro no está en agentes monolíticos que lo hacen todo, sino en ecosistemas de agentes especializados que colaboran, negocian y compiten. La clave del éxito —como ocurre tantas veces en ingeniería— está en dominar primero los fundamentos. Entender el patrón baseline, saber cuándo un solo agente es suficiente y cuándo hace falta un sistema multi-agente, y elegir el framework de orquestación adecuado para cada caso: ese es el camino para construir AI Agents que realmente funcionen.

El glosario de IA de Vientos de Poniente ofrece definiciones detalladas de todos los conceptos mencionados en este artículo, desde LLM y skills hasta workflow, LangGraph, CrewAI y MCP.

Fuentes y referencias

Multi Agent Systems Explained — Curso sobre patrones de sistemas multi-agente. Incluye el patrón baseline (LLM + tools) y la progresión hacia arquitecturas multi-agente. Ver vídeo en YouTube
LangGraph Multi-Agent Orchestration Framework — Transcript sobre la capa de orquestación con LangGraph conectado a Mosaic AI Agent Framework, manejo multi-agente. Ver vídeo en YouTube
Harnesses in AI: A Deep Dive — Tejas Kumar (IBM) sobre la construcción de sistemas multi-agente con watsonx.ai y react prompting. Ver vídeo en YouTube
LangGraph Documentation — Documentación oficial
CrewAI Framework — Documentación oficial
OpenAI Agents SDK — Guía oficial
AutoGen (Microsoft Research) — Documentación
Model Context Protocol (MCP) — Especificación oficial
Glosario completo de IA — Vientos de Poniente

31 mayo 2026

El proceso paso a paso

1. Obtener el corpus

2. Entrenar el BPE

3. Los resultados

El tokenizador está disponible

Qué hemos aprendido

📚 Fuentes y recursos