5. Casos de uso y elección de arquitectura

1 · QUÉ ES — PARA PROFANOS

Es la primera responsabilidad que pide la JD: "analizar casos de uso y seleccionar el enfoque,

modelo y arquitectura más adecuados". En llano: cuando alguien de negocio dice "queremos IA",

alguien tiene que preguntar antes "¿para qué, exactamente?". Y la respuesta a esa pregunta decide

todo lo demás.

La metáfora del médico: antes de recetar, el médico pregunta. No prescribe antibióticos porque

alguien diga "estoy mal": pregunta síntomas, historial y contexto. Elegir arquitectura sin

analizar el caso de uso es recetar sin diagnosticar — y el 90 % de los proyectos de IA que

fracasan, fracasan ahí: en el caso de uso, no en la tecnología.

La pregunta que cambia todo: "¿qué decisión va a tomar alguien con la respuesta de este

sistema?"

- Si la respuesta no cambia ninguna decisión → no hace falta IA: hace falta un informe.

- Si la respuesta informa a una persona → LLM + RAG, con cita y cautela.

- Si la respuesta actúa directamente → agente con reglas duras, validación y registro (documento

08).

- Si el problema es clasificar o predecir un número → ML clásico. Un LLM es el instrumento

equivocado.

Esa sola pregunta separa a un arquitecto de un aficionado. La JD la llama "identificación de

casos de uso"; en la práctica es esto.

El patrón estándar de selección, en tres filtros:, Filtro, Pregunta, Qué decide,, Valor, ¿qué decisión cambia?, si el proyecto existe siquiera,, Viabilidad, ¿está el conocimiento disponible y con permiso?, RAG o no RAG, datos o no datos,, Riesgo, ¿qué pasa si se equivoca, y delante de quién?, cuánta verificación, cuánto humano, Los errores típicos que comete la industria (y que un senior debe saber nombrar):

1. "Chatbot de todo" — meter un LLM en cada pantalla. Resultado: coste por token en tareas que

una regla hacía gratis.

2. GenAI donde bastaba un buscador — si el usuario necesita encontrar, un buscador híbrido es

más barato y más fiable que generar prosa.

3. Fine-tuning prematuro — entrenar un modelo antes de agotar prompt + RAG (documento 01).

4. Piloto sin criterio de éxito — "probemos a ver" sin definir qué métrica decide si sigue.

Resultado: demos eternas.

La práctica seria: cada caso de uso se escribe como ficha — decisión que cambia, datos,

permisos, riesgo, métrica de éxito, coste estimado por consulta. Las fichas se priorizan por valor

y por lo que se puede medir. Lo que no se puede medir no se prioriza.

- "AI Engineering" como disciplina: en los equipos de 2025-2026, el rol ya no es "científico de

datos" sino ingeniero de IA: alguien que monta sistemas con modelos, como se montan sistemas

con bases de datos. Es exactamente la JD de Getnet.

- Casos de uso agénticos: la frontera se mueve de "responder preguntas" (RAG simple) a "hacer

tareas de varios pasos" (agentes). La selección de caso de uso ahora incluye la pregunta "¿esto

es una pregunta o es un proceso?".

- RAG como función, no como proyecto: lo que antes era un proyecto de 6 meses ahora es una

pieza estándar. La decisión interesante ya no es "¿montamos RAG?" sino "¿qué control de acceso

y qué evaluación le ponemos?" — que es justo lo que pide la JD.

- ROI medido por consulta: con los precios por token, cada caso de uso se justifica con coste

por pregunta respondida. Los equipos que no miden coste por consulta se encuentran con la factura

de la nube tres meses después. Nuestra lección de las facturas de Copilot es la versión

doméstica de este problema.

Nuestro método son tres preguntas, en orden fijo, antes de elegir herramienta:, #, Pregunta, Qué decide,, 1, ¿Cuánto conocimiento hay y cuánto cambia?, si hace falta RAG, índice vectorial o búsqueda simple,, 2, ¿Qué cuesta equivocarse, y delante de quién?, cuánta verificación, cuánto humano, cuánto guardrail,, 3, ¿Dónde puede estar el dato y qué exige el regulador?, qué nube, qué cifrado, qué trazabilidad, Cuatro decisiones reales tomadas con este método:

1 · El caso clínico (RADIA). Pregunta 2: equivocarse cuesta un diagnóstico — delante de un

médico. Decisión: no un modelo, sino tres en funciones distintas, donde uno puede contradecir

al otro y el castigo pesa el doble que el premio (documento 05).

2 · El caso de interacción (ResonIA). Pregunta 2 y 3: se analizan personas y voz. Decisión:

reglas en el esquema de datos — el tipo que guarda un hallazgo no tiene casilla para

diagnosticar ni culpar (documento 08).

3 · El mismo dominio, dos nubes (SentryAI y Contorn). Misma seguridad de perímetro. Pregunta 3:

el comprador corporativo exige SSO y trazabilidad por rol → Azure. El comprador de coste cero →

Cloudflare. Elijo la nube por comprador, no por preferencia.

4 · El nodo de 242 MB (Neferu). Pregunta 1 y 3: mucho conocimiento, pero el hardware no admite

un modelo de embeddings. Decisión: TF-IDF en 41 líneas — porque la pregunta correcta no era

"¿qué RAG montamos?" sino "¿qué RAG cabe aquí?" (documento 03).

El principio que resume el método: "depende" sin criterio detiene una conversación técnica.

Tres preguntas la convierten en un método repetible — y cualquiera del equipo puede aplicarlo sin

mí.

> "Antes de elegir herramienta hago siempre tres preguntas: cuánto conocimiento hay y cuánto

> cambia; qué cuesta equivocarse y delante de quién; y dónde puede estar el dato. Con esas tres he

> tomado decisiones muy distintas — tres modelos auditándose en clínica, reglas en el esquema para

> voz, y TF-IDF para un nodo de 242 MB. La herramienta es la consecuencia; el análisis es el

> trabajo."

> "Analizar casos de uso y seleccionar el enfoque, modelo y arquitectura más adecuados." ·

> "Capacidad para convertir necesidades de negocio en soluciones técnicas basadas en IA." ·

> "Capacidad de experimentación y prototipado rápido."

La lectura: es el objetivo del puesto, literal. No buscan solo un constructor: buscan a

alguien que decida qué merece construirse y con qué.

"¿Cómo decides si un caso de uso merece IA?"

> "Con una pregunta que hago siempre: ¿qué decisión va a cambiar con la respuesta? Si la respuesta

> no cambia ninguna decisión, no hace falta IA — hace falta un informe. Si informa a una persona,

> RAG con cita. Si actúa sola, agente con reglas duras. Si es clasificar o predecir, ML clásico. La

> mitad de los casos que llegan con la etiqueta 'IA' se resuelven mejor sin un LLM, y decirlo a

> tiempo es parte del trabajo."

"Cuéntame un caso de uso que hayas llevado de idea a producción."

> "El control de calidad de interacciones: llamadas y conversaciones con voicebots. La necesidad

> era '¿cómo sé si mis agentes responden bien?'. La decisión que cambiaba: qué se corrige en el

> guion y qué formación se da. Ahí decidí dos cosas: la regla vive en el esquema de datos —un

> hallazgo no puede diagnosticar ni culpar, porque el tipo no tiene casilla— y sin cita textual del

> transcript el hallazgo se descarta. Hoy son 8.660 líneas en producción, con vocabulario

> controlado. El caso de uso era 'medir calidad'; la arquitectura vino sola de las restricciones."

"¿Prototipas rápido o diseñas primero?"

> "Prototipo rápido para validar la decisión, diseño lento para lo que queda. La regla que sigo:

> el prototipo contesta '¿se puede?'; la arquitectura contesta '¿se puede defender?'. Y nunca dejo

> que el prototipo se convierta en producción por inercia — cuando lo hace, es exactamente cuando

> los sistemas empiezan a mentir sobre su propia calidad."