Módulo 1: ¿Qué es AI Realmente?

5. AI en 2024-2026: Estado actual, qué es posible y qué no

Descripción

En esta cápsula vas a situar la inteligencia artificial en el presente: qué es razonable esperar hoy y en los próximos años, qué es exageración o mito, y qué tendencias marcan el rumbo del campo. No son predicciones infalibles; son un marco para leer noticias, evaluar productos y tomar decisiones sobre tu carrera o tu uso de AI.

El objetivo es que tengas una visión realista: ni "todo es humo" ni "en dos años hay AGI". La AI actual es muy potente en dominios concretos y sigue mejorando, pero con límites claros. Para un AI Engineer, saber qué es posible hoy (y qué no) te ayuda a diseñar sistemas con expectativas correctas: RAG para reducir alucinaciones, evaluación para detectar fallos, fallbacks cuando el modelo no responde bien.

Por qué el estado actual importa para tu trabajo

Antes de entrar en "qué es posible" y "qué no", conviene tener claro para qué sirve esta cápsula si vas a trabajar con AI:

Diseñar con expectativas correctas. Si asumes que el modelo "nunca alucina" o "recuerda todo", diseñarás productos que fallan en producción. Si asumes que las alucinaciones son un límite estructural y que el contexto es finito, diseñarás RAG, verificación y fallbacks desde el principio.
Elegir stack. El estado actual (APIs, RAG, agents, modelos open source, regulación) determina qué herramientas usas: qué proveedor, si RAG o fine-tuning, si agent o flujo fijo, si API gestionada o modelo propio.
Leer noticias y anuncios con ojo crítico. "Revolucionario", "cambia todo", "AGI a la vuelta de la esquina" son afirmaciones que puedes contrastar con lo que realmente es posible hoy (y con la historia de ciclos de hype que viste en la cápsula 03).
Comunicar con producto y negocio. Saber qué es posible (y qué no) te permite explicar por qué un producto debe incluir revisión humana, por qué RAG reduce errores, o por qué "sustituir por completo a X" no es realista hoy.

Qué es posible hoy (2024-2026)

Lenguaje (texto)

Generar texto coherente, resúmenes, traducciones, borradores, código a partir de descripciones.
Responder preguntas sobre documentos (RAG) o conocimiento hasta cierta fecha.
Conversar con contexto limitado (ventana de contexto de varios miles o cientos de miles de tokens).
Clasificar y extraer información de texto (entidades, sentimiento, temas).

Límites conocidos: Alucinaciones (inventar datos o hechos), inconsistencia en razonamiento largo, sensibilidad al prompt, coste y latencia en modelos muy grandes. Por eso en aplicaciones críticas se usa RAG (conectar el modelo a documentos o bases de datos) y evaluación humana o automática. Las alucinaciones no se "arreglan" con un parche; se mitigan con diseño (RAG, verificación externa, supervisión humana cuando aplica).

Por qué importa para un AI Engineer: Tu trabajo es elegir el modelo, diseñar prompts, conectar con conocimiento propio (RAG) y evaluar respuestas. Saber que las alucinaciones son un límite estructural (no un bug que se arregla con un parche) te lleva a diseñar pipelines que verifican, contrastan o acotan las respuestas. No asumas "el modelo nunca inventa datos"; diseña para el caso en que lo haga (citar fuentes, contrastar con base de datos, pedir confirmación humana en usos críticos).

Imagen y visión

Generar imágenes a partir de descripciones (DALL·E, Midjourney, Stable Diffusion, etc.).
Analizar imágenes: describir escenas, detectar objetos, leer texto (OCR).
Combinar texto e imagen (modelos multimodales que entienden y generan ambos).

Límites conocidos: Detalles finos (manos, texto en imágenes), coherencia en secuencias o escenas muy complejas, derechos de autor y uso ético de datos de entrenamiento. Los modelos de imagen siguen mejorando pero no son perfectos; en producción suele hacerse revisión humana para usos sensibles.

Voz y audio

Reconocer voz (transcripción) con buena precisión en muchos idiomas.
Sintetizar voz muy natural (text-to-speech).
Generar música o efectos a partir de descripciones (aún en desarrollo).

Límites conocidos: Acentos muy marcados, ruido de fondo, idiomas minoritarios, y uso ético de voces clonadas.

Código

Generar código a partir de descripción o de comentarios (Copilot, ChatGPT, Claude, etc.).
Explicar código, refactorizar, detectar bugs o sugerir tests.
Completar líneas o bloques en el editor (autocompletado inteligente).

Límites conocidos: Código muy largo o muy específico, bibliotecas poco vistas en entrenamiento, necesidad de revisión humana para seguridad y corrección.

Integración en productos

APIs de modelos (OpenAI, Anthropic, Google, Meta, Mistral, etc.) para integrar capacidades de lenguaje, visión o audio en aplicaciones.
RAG (Retrieval-Augmented Generation) para conectar LLMs con bases de conocimiento propias.
Agents y tool use: modelos que llaman funciones, buscan información o ejecutan pasos (con supervisión y límites).

Límites conocidos: Coste, latencia, privacidad, dependencia de proveedores, necesidad de diseño cuidadoso (prompts, evaluación, fallbacks). Un AI Engineer tiene que elegir entre APIs gestionadas (más fácil, menos control) y modelos propios o open source (más control, más operación).

Qué no es posible (o no de forma fiable) hoy

Es importante tener claro qué no debes esperar de los sistemas actuales, para no diseñar productos que asuman capacidades que no existen o no son fiables.

AGI (inteligencia general): No existe un sistema que aprenda y realice cualquier tarea intelectual humana.
Razonamiento matemático o lógico perfecto: Los modelos cometen errores en demostraciones, cálculos largos o lógica compleja; hay que verificar.
Memoria y coherencia ilimitadas: El contexto está limitado por la ventana del modelo; no "recuerdan" conversaciones infinitas ni hechos del mundo en tiempo real sin RAG o APIs.
Hechos siempre correctos: Alucinaciones siguen presentes; no son bases de datos fiables sin verificación.
Consciencia o comprensión "real": No hay evidencia de que los sistemas actuales tengan consciencia; son weak AI.
Sustitución completa de expertos en dominios críticos (medicina, derecho, seguridad) sin supervisión humana; se usan como apoyo, no como reemplazo definitivo.

Analogía: Es como un asistente muy listo pero que a veces inventa datos y no recuerda todo lo que le dijiste hace un rato. Útil si diseñas el sistema para verificar, acotar y complementar; peligroso si asumes que "siempre tiene razón" o "recuerda todo".

Tendencias que marcan el rumbo (2024-2026)

Modelos más capaces y más baratos

Modelos de lenguaje y multimodales siguen mejorando en calidad, velocidad y coste por token.
Modelos open source (Llama, Mistral, etc.) permiten correr en propia infra o elegir proveedores.
Competencia entre OpenAI, Anthropic, Google, Meta, Mistral y otros mantiene innovación y opciones.

Multimodalidad y agents

Un mismo modelo que entiende y genera texto, imagen y a veces audio.
Agents que planifican, usan herramientas (búsqueda, código, APIs) y ejecutan pasos; aún con límites pero en evolución.

RAG y conocimiento propio

Conectar LLMs a documentos, bases de datos o APIs para reducir alucinaciones y actualizar conocimiento sin reentrenar.
Patrón central para aplicaciones empresariales (soporte, documentación, análisis interno). Un AI Engineer tendrá que diseñar pipelines de recuperación (embeddings, bases vectoriales), elegir qué documentos incluir y evaluar calidad de respuestas (¿cita fuentes? ¿responde con lo que está en los documentos?).
RAG no elimina alucinaciones al 100 %; las reduce cuando el modelo se acota a fuentes propias. Sigue siendo necesario evaluar y, en usos críticos, verificar o supervisar.

Regulación y estándares

Leyes (ej. UE con AI Act) y códigos de buenas prácticas (transparencia, sesgos, uso de datos).
Impacto en qué se puede desplegar y cómo (documentación, evaluación, supervisión humana).

Coste y acceso

APIs y tiers gratuitos o baratos permiten experimentar; el coste a escala sigue siendo una variable de diseño.
Opciones locales (LM Studio, Ollama) para privacidad o bajo coste en desarrollo.

Small language models (SLMs)

Modelos más pequeños (1-7B parámetros) optimizados para tareas específicas, con coste y latencia mucho menores que los LLMs grandes.
Útiles cuando no necesitas capacidades generales (ej. clasificación, extracción, respuestas en dominio acotado).
Permiten correr en dispositivos (móviles, edge) sin depender de APIs cloud.

Fine-tuning y modelos especializados

Ajustar modelos pre-entrenados con datos propios para mejorar rendimiento en dominio específico.
Cada vez más accesible (APIs de fine-tuning de OpenAI, Anthropic, Hugging Face).
No convierte narrow en general; mejora dentro del dominio narrow.

Por qué importa para un AI Engineer: Tu stack (API vs modelo propio, RAG vs fine-tuning, agents vs flujos fijos) depende de estas tendencias. Seguir evolución de modelos, costes y regulación te ayuda a tomar decisiones de arquitectura y producto.

Cómo leer noticias y anuncios

Cuando leas titulares o anuncios sobre AI, usa estos criterios para no llevarte a engaño:

"Revolucionario", "cambia todo": Tomar con calma; muchas veces es mejora incremental, no salto cualitativo.
Demos y vídeos: Pueden estar editados o ser casos elegidos; pedir evidencia de rendimiento en condiciones reales.
"AGI a la vuelta de la esquina": Hoy no hay consenso ni evidencia de AGI; son proyecciones o opiniones, no hecho.
Comparativas de modelos: Ver fecha, benchmark y condiciones; los rankings cambian y los benchmarks no cubren todos los usos.
"Sustituye a X profesión": En la práctica suele ser "asiste" o "cambia partes del trabajo"; la sustitución total es excepcional y suele requerir supervisión.

Errores frecuentes al interpretar el estado actual

1. "Los LLMs entienden todo lo que dicen"

Error: Atribuir comprensión o consciencia a los modelos.
Realidad: Generan secuencias plausibles según patrones aprendidos; no hay consenso de que "entiendan" en sentido humano. Pueden generar cosas incorrectas o incoherentes sin "darse cuenta".

2. "Con AI ya no hace falta programar"

Error: Creer que la AI sustituye el desarrollo de software.
Realidad: La AI se integra en productos mediante código (APIs, pipelines, evaluación, fallbacks). El rol de programación sigue siendo central; un AI Engineer es sobre todo ingeniero de software que integra modelos.

3. "ChatGPT es AGI"

Error: Tratar los LLMs actuales como inteligencia general.
Realidad: Son narrow AI muy capaces en lenguaje; no generalizan a cualquier tarea intelectual ni existe hoy un sistema que se considere AGI.

4. "Si el modelo falla una vez, no sirve"

Error: Esperar cero errores.
Realidad: Los modelos tienen tasas de error; el diseño del sistema (evaluación, verificación, fallbacks, supervisión humana cuando aplica) es lo que hace que el producto sea fiable, no que el modelo sea perfecto.

Preguntas frecuentes

¿Qué es una alucinación?
Cuando el modelo inventa datos, hechos o referencias que no existen o no son correctos. Es un límite estructural de los LLMs (aprenden patrones, no "saben" hechos); se mitiga con RAG, verificación externa o supervisión humana.

¿Por qué a veces el modelo "olvida" lo que le dije?
La ventana de contexto es limitada (aunque sea de cientos de miles de tokens); fuera de esa ventana el modelo no "ve" el texto. No hay memoria infinita nativa; se simula con RAG, resúmenes o bases de datos externas.

¿Qué modelo debería usar para mi producto?
Depende del uso: coste, latencia, idiomas, necesidad de visión o solo texto, privacidad (¿puedes enviar datos a una API?). No hay una respuesta única; sí conviene probar varios y evaluar en condiciones reales.

¿La regulación (ej. EU AI Act) me afecta?
Sí si despliegas productos en la UE o en sectores regulados (salud, educación, etc.). Conviene revisar requisitos de transparencia, evaluación de riesgos y supervisión humana según el nivel de riesgo del uso.

Comparativa rápida: qué esperar por dominio

Para fijar ideas, aquí va una tabla de qué es razonable esperar hoy (y qué no) por dominio. No es exhaustiva; es un marco para evaluar productos y diseños.

Dominio	Qué es posible hoy	Qué no es fiable (o no existe)
Lenguaje (texto)	Generar, resumir, traducir, clasificar, RAG con documentos	Cero alucinaciones; memoria infinita; razonamiento matemático perfecto
Imagen	Generar desde descripción; describir; detectar objetos; OCR	Detalles perfectos (manos, texto); coherencia infinita en secuencias
Voz	Transcripción; síntesis muy natural; muchos idiomas	Perfecto en acentos muy marcados o ruido extremo; clonación ética
Código	Generar, completar, explicar, refactorizar, sugerir tests	Código que siempre compila y hace exactamente lo que pides sin revisión
Integración	APIs, RAG, agents con herramientas	Coste cero; latencia cero; privacidad total sin trade-offs

Usa esta tabla cuando evalúes un producto o cuando diseñes uno: si tu diseño asume algo de la columna "qué no es fiable", revisa expectativas (verificación, supervisión humana, fallbacks).

Referencia rápida: qué esperar al diseñar

Cuando diseñes un sistema AI, usa esta lista para no asumir capacidades que no existen o no son fiables hoy:

Sí puedes esperar (y diseñar para):

Generar y analizar texto, imagen y voz con buena calidad en dominios acotados.
Integrar modelos vía APIs (OpenAI, Anthropic, Google, Meta, Mistral, etc.).
Conectar LLMs con conocimiento propio (RAG) para reducir alucinaciones en dominio acotado.
Usar agents que planifican y llaman herramientas (con supervisión y límites).
Evaluar respuestas (humanas o automáticas) y definir fallbacks cuando el modelo falle.

No debes asumir (sin diseño explícito):

Cero alucinaciones; diseña RAG, verificación o supervisión humana cuando aplica.
Memoria infinita; el contexto es finito; usa RAG, resúmenes o bases de datos externas si necesitas "recordar" más.
Razonamiento matemático o lógico perfecto; verifica resultados críticos.
Sustitución total de expertos en dominios críticos sin supervisión humana.
Coste o latencia cero a escala; elige modelo y proveedor según restricciones de producto.

Usa esta lista cuando definas expectativas con producto o negocio, o cuando evalúes si un diseño es realista hoy.

Ejemplos por tipo de producto (qué esperar hoy)

Para conectar "qué es posible" con productos concretos, aquí van ejemplos por tipo:

Tipo de producto	Qué es razonable esperar hoy	Qué no debes asumir
Chatbot / asistente de texto	Generar respuestas coherentes, resumir, traducir, responder sobre documentos (RAG)	Cero alucinaciones; memoria infinita; razonamiento matemático perfecto
Recomendaciones (Netflix, Spotify, etc.)	Personalización según historial y preferencias; mejora con más datos	Que nunca falle; que "entienda" tus gustos en sentido filosófico
Generación de imágenes	Imágenes a partir de descripciones; buena calidad en muchos casos	Detalles perfectos (manos, texto); coherencia infinita en secuencias
Transcripción de voz	Buena precisión en muchos idiomas y acentos	Perfecto en ruido extremo o acentos muy marcados
Asistente de código (Copilot, etc.)	Completar líneas, generar código a partir de descripción, explicar código	Que siempre compile y haga exactamente lo que pides sin revisión
RAG (preguntas sobre documentos)	Respuestas acotadas a fuentes propias; menos alucinaciones que sin RAG	Cero alucinaciones; que nunca cite mal o invente fuentes

Usa esta tabla cuando evalúes un producto o cuando definas expectativas para uno que estés diseñando.

Resumen en una página

Qué es posible hoy: Generar y analizar texto, imagen y voz; integrar modelos vía APIs; RAG y agents con límites conocidos.
Qué no es posible (o no fiable): AGI; razonamiento perfecto; memoria ilimitada; cero alucinaciones; sustitución total de expertos sin supervisión.
Límites estructurales: Alucinaciones (mitigar con RAG, verificación); contexto finito (usar RAG, resúmenes); coste y latencia (elegir modelo y proveedor).
Tendencias: Modelos más capaces y baratos; multimodalidad; agents; RAG; regulación (EU AI Act).
Leer con ojo crítico: "Revolucionario", "AGI a la vuelta de la esquina", "sustituye a X profesión" → contrastar con evidencia y condiciones reales.
Para un AI Engineer: Diseñar con expectativas correctas (RAG, evaluación, fallbacks); elegir stack (API vs modelo propio, RAG vs fine-tuning); comunicar límites a producto y negocio.
Errores frecuentes: "Los LLMs entienden todo" (falso); "Con AI ya no hace falta programar" (falso); "ChatGPT es AGI" (falso); "Si el modelo falla una vez, no sirve" (falso).
Recursos: State of AI Report, AI Index (Stanford), McKinsey (estado de AI), EU AI Act, Anthropic/OpenAI (model cards).
Implicaciones para diseño: Cuando diseñes un sistema (RAG, agent, API), usa la tabla "Qué es posible hoy" y "Qué no es posible" para no asumir capacidades que no existen o no son fiables. Diseña RAG, verificación y fallbacks desde el principio.

Resumen de implicaciones para AI Engineering

El estado actual de la AI tiene consecuencias directas en cómo trabajas como AI Engineer:

Diseña con expectativas correctas. Si asumes que el modelo "nunca alucina" o "recuerda todo", diseñarás productos que fallan en producción. Si asumes que las alucinaciones son un límite estructural y que el contexto es finito, diseñarás RAG, verificación y fallbacks desde el principio.
Elige stack según lo posible hoy. El estado actual (APIs, RAG, agents, modelos open source, regulación) determina qué herramientas usas: qué proveedor, si RAG o fine-tuning, si agent o flujo fijo, si API gestionada o modelo propio.
Comunica límites a producto y negocio. Usa la tabla "Qué es posible hoy" y "Qué no es posible" de esta cápsula. Si el producto asume cero alucinaciones o memoria infinita, explica que son límites estructurales y que se mitigan con RAG, verificación y fallbacks.
Lee noticias y anuncios con ojo crítico. "Revolucionario", "cambia todo", "AGI a la vuelta de la esquina" son afirmaciones que puedes contrastar con lo que realmente es posible hoy y con la historia (cápsula 03: ciclos de hype).
Usa la tabla "Ejemplos por tipo de producto" cuando evalúes. Cuando evalúes un producto o definas expectativas para uno que estés diseñando, usa la tabla "Ejemplos por tipo de producto" de esta cápsula para no asumir capacidades que no existen o no son fiables.
Usa la tabla "Comparativa rápida: qué esperar por dominio" cuando definas expectativas. La tabla (lenguaje, imagen, voz, código, integración) te ayuda a no asumir "qué no es fiable" (cero alucinaciones, memoria infinita, etc.) cuando diseñes o evalúes un producto.

Usa este resumen cuando definas expectativas, cuando elijas stack o cuando comuniques límites a producto y negocio.

Notas para profundizar

¿Por qué las alucinaciones no se "arreglan" con un parche? Porque son un límite estructural de cómo funcionan los LLMs (aprenden patrones, no "saben" hechos). Se mitigan con diseño: RAG (conectar a fuentes propias), verificación externa, supervisión humana cuando aplica. No asumas "el modelo nunca inventa datos"; diseña para el caso en que lo haga.

¿Qué hacer cuando definas expectativas con producto o negocio? Usa la tabla "Qué es posible hoy" y "Qué no es posible" de esta cápsula. Si el producto asume cero alucinaciones o memoria infinita, revisa expectativas (RAG, verificación, fallbacks). Si el producto asume "sustitución total de X profesión", matiza: en la práctica suele ser "asiste" o "cambia partes del trabajo".

¿Cómo usar esta cápsula en el bootcamp o en otra guía? Cuando diseñes un sistema (RAG, agent, API), recuerda qué es posible hoy (y qué no). Eso determina tu stack (qué modelo, si RAG o fine-tuning, si verificación humana) y tu comunicación con producto y negocio (límites, evaluación, supervisión).

¿Qué preguntas hacer cuando oigas "revolucionario" o "cambia todo"? ¿En qué benchmark? ¿Bajo qué condiciones? ¿Comparado con qué? Contrasta con evidencia (benchmarks, condiciones reales de uso) y con la historia (cápsula 03: ciclos de hype).

Preguntas para reflexionar

¿Por qué las alucinaciones no se "arreglan" con un parche? Porque son un límite estructural de los LLMs (aprenden patrones, no "saben" hechos). Se mitigan con diseño: RAG (conectar a fuentes propias), verificación externa, supervisión humana cuando aplica.

¿Por qué el modelo "olvida" lo que le dije? Porque la ventana de contexto es limitada (aunque sea de cientos de miles de tokens); fuera de esa ventana el modelo no "ve" el texto. No hay memoria infinita nativa; se simula con RAG, resúmenes o bases de datos externas.

¿Por qué no debes asumir "sustitución total de X profesión"? Porque en la práctica suele ser "asiste" o "cambia partes del trabajo"; la sustitución total es excepcional y suele requerir supervisión humana. En dominios críticos (medicina, derecho, seguridad) se usan como apoyo, no como reemplazo definitivo.

¿Qué tendencia te afecta más como AI Engineer? Depende de tu contexto: RAG (diseñar pipelines de recuperación, embeddings, bases vectoriales); agents (diseñar flujos y herramientas); regulación (documentación, evaluación de riesgos); multimodalidad (productos que combinan texto e imagen).

¿Cómo comunicar límites a producto o negocio? Usa la tabla "Qué es posible hoy" y "Qué no es posible" de esta cápsula. Si el producto asume cero alucinaciones o memoria infinita, explica que son límites estructurales y que se mitigan con RAG, verificación y fallbacks.

Resumen ejecutivo (para repaso rápido)

Posible hoy: Generar/analizar texto, imagen, voz; APIs; RAG; agents con límites.
No posible (o no fiable): AGI; razonamiento perfecto; memoria infinita; cero alucinaciones; sustitución total sin supervisión.
Límites: Alucinaciones (RAG, verificación); contexto finito (RAG, resúmenes); coste/latencia (elegir modelo).
Tendencias: Modelos más capaces y baratos; multimodalidad; agents; RAG; regulación.
Leer con ojo crítico: "Revolucionario", "AGI ya", "sustituye a X" → contrastar con evidencia.
Para AI Engineer: Expectativas correctas (RAG, evaluación, fallbacks); elegir stack; comunicar límites.
Errores: "LLMs entienden todo" (falso); "Con AI no hace falta programar" (falso); "ChatGPT es AGI" (falso); "Si falla una vez, no sirve" (falso).
Recursos: State of AI Report, AI Index, McKinsey, EU AI Act, Anthropic/OpenAI (model cards).

Conexión con el resto de la guía

Módulo 6 (APIs): El estado actual es el que hace que "integrar un LLM vía API" sea el pan de cada día para un AI Engineer.
Módulo 7 (AI Engineering): Tu rol existe porque hay modelos potentes pero con límites; tu trabajo es diseñar sistemas que los usen bien (RAG, prompts, evaluación, fallbacks).
Módulo 8 (Diseño): Diseñar un sistema AI hoy significa elegir tareas posibles (narrow AI), modelos y APIs, y asumir límites (alucinaciones, contexto, coste) de forma explícita.

Ejercicios

Ejercicio 1: ¿Posible hoy o no?

Indica si es razonable esperarlo hoy (2024-2026) con sistemas existentes (sí/no) y por qué en una frase:

Traducir un documento largo entre dos idiomas con buena calidad.
Un modelo que nunca inventa un hecho incorrecto.
Un chatbot que recuerda toda la conversación de hace un año sin límite de contexto.
Generar código que siempre compila y hace exactamente lo que pides sin revisión.

Ver solución

Sí. Traducción automática con LLMs o sistemas dedicados es posible y se usa en producción; la calidad es buena en muchos pares de idiomas.
No. Los LLMs pueden alucinar; no hay garantía de cero errores de hecho sin verificación externa (RAG, bases de datos, humanos).
No. La ventana de contexto es limitada (aunque sea grande); no hay "memoria" infinita nativa; se simula con RAG o resúmenes, no con contexto completo de un año.
No. La generación de código requiere revisión humana; no hay garantía de corrección ni de que compile siempre sin iterar.

Ejercicio 2: Mitos en una frase

Escribe una frase que corrija cada mito:

A) "Los LLMs entienden todo lo que dicen."
B) "Con AI ya no hace falta programar."
C) "ChatGPT es AGI."

Ver guía de respuesta

Guía:
A) Los LLMs generan secuencias plausibles según patrones aprendidos; no hay consenso de que "entiendan" en sentido humano; pueden generar cosas incorrectas o incoherentes.
B) La AI se integra en productos mediante código (APIs, pipelines, evaluación); el rol de programación sigue siendo central, sobre todo en AI Engineering.
C) ChatGPT es narrow AI muy capaz en lenguaje; no es AGI: no generaliza a cualquier tarea intelectual ni existe hoy un sistema que se considere AGI.

Ejercicio 3: Tendencia que te afecta

Elige una tendencia (modelos más baratos, RAG, agents, regulación, multimodalidad) y explica en 2–3 frases cómo puede afectar al trabajo de un AI Engineer en los próximos años.

Ver guía de respuesta

Guía (ejemplo con RAG): "RAG se ha vuelto un patrón estándar para conectar LLMs con conocimiento propio; un AI Engineer tendrá que diseñar pipelines de recuperación, elegir embeddings y bases vectoriales, y evaluar calidad de respuestas. Quien no sepa diseñar y mantener RAG tendrá menos ventaja en aplicaciones empresariales."

Puedes hacer lo mismo con otras tendencias (agents → diseñar flujos y herramientas; regulación → documentación y evaluación; multimodalidad → productos que combinan texto e imagen).

Ejercicio 4: Límite y mitigación

Para cada límite, escribe una forma razonable de mitigarlo en un producto real (una frase por límite):

Alucinaciones (inventar hechos).
Ventana de contexto limitada (el modelo "olvida").
Coste alto a escala.

Ver guía de respuesta

Guía (ejemplos):

Conectar el modelo a documentos o bases de datos (RAG) para que cite fuentes; verificación externa o supervisión humana en usos críticos.
Resumir conversaciones largas; usar RAG para recuperar información relevante; guardar contexto en base de datos y inyectarlo cuando haga falta.
Elegir modelos más pequeños o más baratos cuando la tarea no requiera el más capaz; cachear respuestas; usar tiers o modelos open source para desarrollo.

Ejercicio 5: ¿Mito o realidad?

Indica si es mito o realidad (y por qué en una frase):

A) "Un LLM puede recordar toda una conversación de un año."
B) "Un LLM puede generar código que compile siempre sin revisión."
C) "RAG reduce alucinaciones al conectar el modelo a fuentes propias."

Ver solución

A) Mito. La ventana de contexto es limitada; no hay memoria infinita nativa; se simula con RAG o resúmenes, no con contexto completo de un año.
B) Mito. La generación de código requiere revisión humana; no hay garantía de corrección ni de que compile siempre sin iterar.
C) Realidad. RAG conecta el modelo a documentos o bases de datos; eso acota las respuestas a fuentes concretas y reduce (no elimina) la invención de hechos.

Ejercicio 6: Titular crítico

Un titular dice: "Nuevo modelo supera a humanos en razonamiento matemático." Escribe 2–3 preguntas que harías para evaluar si la afirmación es sólida (benchmark, condiciones, tipo de problemas).

Ver guía de respuesta

Guía (ejemplos): ¿En qué benchmark? ¿Qué tipo de problemas (aritmética básica vs demostraciones largas)? ¿Bajo qué condiciones (sin herramientas, con calculadora)? ¿Comparado con qué nivel de humano (estudiante, experto)? ¿El modelo comete errores en algún porcentaje de casos? ¿Los resultados son reproducibles?

Resumen

En una frase - Estado actual (2024-2026): Narrow AI muy capaz en dominios específicos (lenguaje, imagen, voz), con límites claros (alucinaciones, contexto, coste) y mejora continua; AGI no existe.

Puntos clave:

Hoy es posible: Generar y analizar texto, imagen y voz; integrar modelos vía APIs; usar RAG y agents con límites conocidos.
Hoy no es posible (o no fiable): AGI, razonamiento perfecto, memoria ilimitada, cero alucinaciones, sustitución total de expertos sin supervisión.
Tendencias relevantes: Modelos más capaces y baratos, multimodalidad, agents, RAG, regulación y estándares.
Leer con ojo crítico: Desconfiar de "revolución total" y "AGI ya"; contrastar demos con evidencia y condiciones reales de uso.
Para un AI Engineer: El estado actual implica integrar narrow AI potente, asumir límites y diseñar sistemas (RAG, evaluación, fallbacks) que funcionen en producción.

Recursos adicionales

The State of AI Report (anual) — Resumen anual del estado del campo: modelos, inversión, regulación y tendencias; útil para tener una visión actualizada (en inglés). Complementa la sección "Tendencias" de esta cápsula.
AI Index (Stanford HAI) — Datos y tendencias sobre investigación, inversión y adopción; complementa el report anterior con métricas (en inglés). Útil para contrastar afirmaciones con datos.
McKinsey: The state of AI (2024) — Uso de AI en empresas, expectativas y casos de uso; perspectiva de negocio (en inglés). Conecta "qué es posible hoy" con adopción en empresas.
EU AI Act — Marco regulatorio en la UE; niveles de riesgo, obligaciones y plazos; relevante si despliegas en Europa (en inglés).
Anthropic: Claude Model Card — Documentación de capacidades y límites de Claude; ejemplo de cómo un proveedor comunica qué puede y qué no puede un modelo (en inglés).
OpenAI: GPT-4 System Card — Resumen de capacidades, límites y riesgos de GPT-4; útil para conectar "estado actual" con un modelo concreto (en inglés).

← Anterior4. Tipos de AI: Narrow vs General, Weak vs Strong Siguiente →6. Ejercicio: AI a tu alrededor