La IA dentro de una aplicación
Antes de tocar ningún modelo, hay que decidir dónde vivirá el código que habla con él, para que todo lo que venga después quede ordenado y separado de la lógica de negocio.
Tiempo de lectura: 3 min
La capa de IA
La capa de IA es la parte de la aplicación que concentra todo el código que habla con modelos de lenguaje. En lugar de repartir llamadas a la API por los controladores o por los modelos de datos, se agrupan en un lugar propio, con sus clases, su configuración y sus tests.
El motivo es que un LLM es una frontera con un sistema externo que tiene tres propiedades incómodas: no es determinista (la misma pregunta puede tener respuestas distintas), es de pago (cada llamada cuesta dinero) y es lento (segundos, no milisegundos). Todo lo que tenga estas propiedades conviene aislarlo, igual que aislarías una pasarela de pago.
Tenerlo aislado es lo que después te permite versionar los prompts, hacer tests sin llamadas reales, medir costes o cambiar de modelo sin tocar el resto de la aplicación.
Servicio de dominio
Un servicio de dominio expone una operación con nombre de negocio, como resumirTicket($ticket) o sugerirRespuesta($ticket), y oculta los detalles: qué modelo se usa, con qué prompt, con qué parámetros y cómo se interpreta la respuesta.
Quien lo llama no tiene por qué saber que hay un LLM detrás. Esto permite cambiar el prompt, añadir una caché o sustituir el modelo por una regla simple sin modificar ningún otro punto del código. También facilita los tests, porque puedes sustituir el servicio por una respuesta simulada.
Llamadas síncronas y colas
Una llamada síncrona hace esperar al usuario hasta que el modelo responde; una cola (un trabajo en segundo plano) acepta la petición, responde enseguida al usuario y la procesa después. Con modelos que tardan entre 2 y 30 segundos, esta decisión afecta directamente a la experiencia de usuario y a la robustez.
Regla práctica: si el usuario necesita el resultado para continuar y la llamada es corta, puede ser síncrona. Si es larga, masiva o puede fallar y hay que reintentarla (procesar 500 tickets, indexar documentos), va a la cola. Las colas también te dan reintentos automáticos cuando el proveedor falla o limita las peticiones.
Abstracción del proveedor
La abstracción del proveedor es una capa, propia o de un SDK, que unifica la forma de hablar con OpenAI, Anthropic, Google o un modelo abierto, de modo que cambiar de proveedor sea un cambio de configuración y no una reescritura.
Los modelos cambian de precio, de calidad y de disponibilidad cada pocos meses, y a menudo conviene usar modelos distintos para tareas distintas. Sin esta capa, cada cambio obliga a tocar código repartido por toda la aplicación. Con ella, incluso puedes hacer que, si un proveedor cae, la petición pase a otro.
Revisión humana desde el diseño
Diseñar con revisión humana significa que lo que genera la IA entra como propuesta (un borrador, una sugerencia) que una persona valida antes de que tenga efectos reales, como enviar una respuesta a un cliente o emitir un reembolso.
No es una medida temporal hasta que el modelo «sea lo bastante bueno»: es lo que hace viable poner IA en procesos reales desde el primer día, porque los errores del modelo nunca llegan directamente a producción. A medida que tienes datos de cuántas propuestas se aceptan sin cambios, puedes decidir dónde tiene sentido darle más autonomía.
Examínate de este módulo
Copia este prompt y pégalo en tu IA (ChatGPT, Claude, Gemini…). Te hará un test de 20 preguntas sobre los conceptos del módulo y después te propondrá un ejercicio práctico.
Actúa como examinador de la «Guía de Ingeniería IA» de Dani Pérez. Examíname del módulo «La IA dentro de una aplicación» (https://daniperez.pro/resources/ai-engineering-guide/ai-layer). Conceptos que entran en el examen: - La capa de IA - Servicio de dominio - Llamadas síncronas y colas - Abstracción del proveedor - Revisión humana desde el diseño Examen: 1. 20 preguntas tipo test, cada una con 4 opciones (a, b, c, d) y una sola respuesta correcta. 2. Pregunta sobre comprensión y criterio (para qué sirve cada cosa y cuándo NO usarla), no sobre memorizar definiciones. 3. Reparte la posición de la respuesta correcta de forma equilibrada entre a, b, c y d. 4. Hazme las preguntas en 4 tandas de 5. No pongas ningún ejemplo de respuesta (como "1a 2b 3c 4d 5a"): yo ya sé que debo responder con las letras. No me digas si he acertado hasta que haya respondido las 20. 5. Al final, corrígelas todas: para cada pregunta, mi respuesta, la correcta y una explicación breve. Dame la nota sobre 20 y dime qué conceptos debo repasar. Ejercicio práctico (después de la corrección): 6. Pregúntame qué aplicación tengo o quiero construir, y con qué lenguaje y framework trabajo. Si no tengo ninguna, usa esta: la aplicación de atención al cliente de una tienda online, con tickets, clientes, pedidos y una base de conocimiento (FAQ y políticas de devolución). En ese caso, centra el ejercicio en: diseñar dónde vive la capa de IA y hacer una primera llamada al modelo encapsulada detrás de un método de dominio. 7. Propónme un ejercicio que aplique los conceptos de este módulo a esa aplicación: objetivo, requisitos, criterios para darlo por bueno y errores habituales a evitar. 8. No me lo resuelvas. Cuando te traiga mi solución, revísala con esos criterios.