Diseño de soluciones de IA · Granada / Remoto

Diseño de soluciones de IA

Antes de escribir código hay una decena de decisiones que condicionan el coste, la latencia y la fiabilidad de todo lo que venga después. Diseño la arquitectura, elijo los modelos con criterio y dejo un roadmap por fases con criterios de éxito. El entregable es un documento con el que tu equipo puede construir, contigo o sin mí.

Este servicio es para equipos que ya han decidido que van a construir algo con IA y quieren acertar la arquitectura antes de invertir seis meses en ella. También para CTOs y responsables de producto que necesitan una segunda opinión técnica: alguien que haya llevado un sistema de IA a producción y no tenga nada que ganar recomendando la opción más cara.

En esta fase no escribo código. Reviso lo que hay, hablo con tu equipo y dejo por escrito las decisiones con sus motivos, incluidas las alternativas que se descartaron y la razón. Si de ese trabajo sale que lo mejor es comprar una herramienta existente, o no hacer nada por ahora, eso es lo que dirá el documento. Y si lo que necesitas es que alguien empiece a construir ya, la fase que buscas es la de implementación.

  • Tienes un piloto que funcionó en la demo y lleva meses sin llegar a producción, y nadie sabe decir exactamente qué falta.
  • El coste de API se ha disparado y no tienes visibilidad de a qué operación corresponde cada euro.
  • El sistema responde bien la mayoría de las veces, y nadie sabe cuántas son «la mayoría» porque no hay forma de medirlo.
  • Estás entre construir a medida o comprar una herramienta, y las dos opciones tienen defensores dentro de casa.
  • Empiezas de cero y quieres que las decisiones de modelo, datos y evaluación estén tomadas antes de contratar o de asignar al equipo.
  • No encaja si ya tienes dentro a quien haga este trabajo: si tu arquitecto o tu equipo de plataforma tiene criterio en IA y tiempo para dedicarle, pagar una fase de diseño externa es comprar una opinión que ya está en casa. Tampoco si el alcance es una única funcionalidad acotada, donde diseñar y construir de una vez sale más barato.
Documento de arquitectura

Diagrama de componentes, flujo de datos de principio a fin y las decisiones tomadas con su justificación: qué se descartó, por qué y qué tendría que cambiar para revisarlo. Escrito para que lo entiendan tanto un ingeniero como un comité de dirección.

Selección de modelos con criterio

Comparativa razonada entre proveedores y tamaños de modelo para tu caso concreto, con el equilibrio entre coste, latencia y calidad explícito. Incluye qué partes conviene resolver sin LLM, que casi siempre son más de las que parece.

Estimación de coste por operación

Cuánto cuesta una consulta, un documento procesado o un caso resuelto, y cómo evoluciona esa cifra al multiplicar el volumen. Es el número que decide si el proyecto tiene sentido económico antes de construirlo.

Estrategia de evaluación y de datos

Cómo vais a medir la calidad: qué casos forman el conjunto de evaluación, quién los revisa, qué umbral se considera aceptable para salir a producción y qué datos hacen falta para llegar hasta ahí.

Roadmap por fases

Un plan por fases con criterios de éxito y de abandono en cada una. Cada fase deja algo utilizable y tiene un punto explícito en el que parar es un resultado legítimo si los números no acompañan.

Sesión de trabajo con el equipo

Una sesión final para revisar el documento con quien va a construirlo, resolver dudas y ajustar lo que no encaje con tu realidad operativa. El objetivo es que el equipo lo defienda como propio.

Diseño desde las restricciones, no desde la tecnología. Primero el volumen esperado, el presupuesto por operación, la latencia que tolera quien va a usarlo y qué datos pueden salir de tu perímetro; las decisiones sobre modelos, RAG, agentes o fine-tuning caen casi solas después. Conozco los tres grandes proveedores comerciales y las opciones abiertas desplegables en infraestructura propia, y no tengo acuerdo comercial con ninguno. La recomendación depende de tu caso, y el documento explica en qué condiciones dejaría de ser válida.

Arquitectura de sistemasClaude / GPT / GeminiRAGAgentesEvalsCoste por consultaSeguridad de datos
01
Inmersión

Entrevistas con negocio y con ingeniería, revisión del código o del piloto si existe, y acceso a una muestra de los datos. Necesito entender las restricciones reales antes que la idea. Una semana.

02
Diseño y contraste

Arquitectura, comparativa de modelos y números de coste. Cuando una decisión depende de algo que no se puede saber sin probarlo, hago una prueba acotada en lugar de suponer. Comparto borradores a mitad de camino para que no haya sorpresas al final. De dos a tres semanas.

03
Entrega y sesión de trabajo

Documento final, roadmap y sesión con el equipo. A partir de ahí puedes construirlo internamente, sacarlo a concurso con un pliego que ya tiene sentido técnico, o seguir conmigo en la fase de implementación. Las tres salidas son legítimas y el documento sirve igual en las tres.

Cuéntame tu caso y te digo con franqueza si la IA es la herramienta adecuada — y cómo la implementaría.