Montar una demo de chat sobre un modelo de lenguaje lleva más o menos una semana. Los problemas empiezan después, cuando esa misma funcionalidad tiene que correr con datos de producción, bajo tráfico real, con un coste predecible y sin alucinaciones que dejen en mal lugar a la marca. Para un CTO, un Head of Product o un Head of AI, la pregunta real no es si añadir IA, sino dónde, cómo y con qué manos hacerlo para que la funcionalidad sobreviva al contacto con los usuarios. Ahí es donde las funciones de IA en un producto dejan de ser una demo y se convierten en una pieza de arquitectura que hay que mantener durante años.
Por nuestra experiencia, lo más difícil no es la integración con el modelo, sino la ingeniería que lo rodea: elegir los datos, evaluar la calidad, controlar el coste y gestionar la privacidad. Dentro del RITS Group desarrollamos competencia real en AI/Data, con nuestros equipos de AI/LLM/datos, y hemos entregado proyectos de GenAI, RAG y LLM, entre ellos un asistente de conocimiento basado en IA para un cliente del sector seguros. Llevamos esa experiencia a los productos tecnológicos y cubrimos los roles que suelen faltar en el lado del cliente.
¿Dónde aporta valor real la IA dentro de un producto?
Antes de la pregunta por el modelo viene la pregunta por el lugar. La IA sale a cuenta donde un producto tiene mucho texto no estructurado o trabajo cognitivo repetitivo, no en todas partes. El valor real suele aparecer en unos pocos patrones:
- búsqueda y respuesta a preguntas sobre documentación, una base de conocimiento o el histórico de tickets,
- resumen y extracción de documentos largos, correos y transcripciones,
- apoyo a la decisión de un operador: sugerencias, clasificación, primeros borradores de respuesta,
- automatización de pasos tediosos de un proceso que hoy hace una persona a mano.
Una primera funcionalidad bien elegida tiene algo en común: se puede medir y se puede revertir si falla. Por ahí empezamos, porque limita el riesgo y gana la confianza de la organización para los siguientes pasos.
¿En qué se diferencian las funciones LLM y RAG dentro de un producto?
Esa distinción marca tanto la arquitectura como el coste. Un LLM a secas trabaja con lo que el modelo «sabe» del entrenamiento y con lo que le pones en el prompt, así que es muy bueno generando, reformulando y clasificando, pero no conoce tus datos. RAG (retrieval-augmented generation) añade una capa de recuperación: primero encuentra los fragmentos adecuados de tu conocimiento y solo entonces el modelo responde a partir de ellos, con referencia a la fuente.
En la práctica, la mayoría de las funcionalidades de producto que de verdad ayudan al usuario son RAG, no un LLM pelado. La razón es prosaica: una empresa quiere la respuesta anclada en sus propios documentos y verificable, no en el conocimiento general del modelo. Ese es exactamente el patrón que usamos en el asistente de conocimiento para el cliente de seguros, donde el modelo tenía que responder desde una base concreta y propiedad de la empresa, en vez de adivinar.
¿Cómo se integran y se evalúan los modelos de IA?
La integración es la parte fácil. La difícil es la evaluación, la respuesta a si una funcionalidad es lo bastante buena como para salir a producción. Sin ella, el equipo trabaja a ciegas y reacciona solo cuando los usuarios se quejan.
- Un conjunto de pruebas con preguntas reales y respuestas esperadas, construido junto a expertos de dominio.
- Métricas de calidad ajustadas a la tarea: relevancia de la respuesta, cita de la fuente, tasa de alucinaciones.
- Comparación de modelos y configuraciones (distintos modelos, prompts, parámetros) sobre el mismo conjunto, en vez de elegir uno a ojo.
- Regresión antes de cada publicación, para que un cambio de prompt no rompa lo que ya funcionaba.
Tratamos el modelo como un componente que se prueba y se versiona, no como una caja mágica. Así la decisión de publicar se apoya en números, y no en una demo afortunada.
¿Cómo encajan los agentes de IA en los procesos de entrega y en el producto?
Un agente de IA es un modelo que no solo responde, sino que da pasos: usa herramientas, llama a APIs, encadena varias acciones en un mismo flujo. En un producto funciona donde la tarea tiene un objetivo claro y un resultado medible, por ejemplo atender un ticket o preparar el primer borrador de un documento.
También usamos agentes en nuestro propio lado, dentro del proceso de entrega, para acelerar las partes rutinarias del trabajo de ingeniería. El principio es el mismo en ambos casos: un agente recibe un alcance definido de forma estrecha y límites de permisos duros, no manos libres. Cuanto más autónomo es el paso, más fuertes son los controles a su alrededor, porque el coste de un error crece más rápido que la comodidad de la automatización.
¿Cómo se controla la calidad de los prompts y de las salidas?
Un prompt no es una nota; es un artefacto de producto que se mantiene como el código. Por eso lo guardamos en un repositorio, lo versionamos y lo probamos, en vez de dejarlo en la cabeza de unas pocas personas. Alrededor de las salidas montamos una capa de seguridad que atrapa lo que el modelo no debería devolver.
- Versionado de prompts, ligado a los resultados de la evaluación.
- Validación del formato de salida (por ejemplo JSON obligatorio), para poder procesar el resultado con seguridad.
- Reglas de content safety y filtros de datos sensibles tanto en la entrada como en la salida.
- Monitorización en producción: registro de peticiones, costes y señales de respuestas de baja calidad.
Esa capa decide si una funcionalidad de IA es repetible o depende de la suerte con una consulta concreta.
¿Cuánto cuesta y cómo se gestionan la seguridad y la privacidad del dato?
El coste de la IA en un producto no es una factura, sino la suma de las llamadas al modelo, el almacenamiento vectorial y el mantenimiento. Lo podemos hacer realista ya en la fase de diseño, ajustando el modelo a la tarea (más pequeño y más barato donde eso basta), acortando prompts, cacheando respuestas repetibles y decidiendo qué necesita siquiera llegar a un modelo.
Tratamos la seguridad y la privacidad como condición de entrada, no como un añadido. Cuando trabajamos con datos de un cliente, establecemos pronto dónde se procesan físicamente los datos, si van a un modelo público o a una variante privada, y cómo se anonimizan y se retienen. En proyectos regulados, como los de seguros, son esas decisiones, y no la elección del modelo, las que determinan si una funcionalidad puede publicarse siquiera.
¿Por qué las funciones de IA necesitan a una persona en el circuito?
Porque un modelo puede sonar seguro incluso cuando se equivoca. En funcionalidades que tocan dinero, derecho, salud o reputación de marca diseñamos un human in the loop como decisión deliberada, no como salvaguarda pegada al final. En la práctica eso significa que, ante respuestas de baja confianza, el producto propone en vez de actuar y deja el último paso a una persona. Este montaje permite publicar IA más rápido y con más seguridad, porque la organización no tiene que confiar en el modelo al cien por cien de un día para otro.
¿Qué competencias de IA aportamos al proyecto?
Aunque no hayamos construido exactamente tu tipo de producto, aportamos gente que ya lo ha hecho antes en otros proyectos de GenAI/RAG/LLM. Formamos el equipo alrededor de la tarea concreta, no «por si acaso»:
- ingenieros de AI/ML y LLM que construyen las funcionalidades, los prompts y la capa RAG,
- data engineers que limpian y preparan el conocimiento para la recuperación,
- arquitectos que unen modelo, backend e infraestructura en un conjunto mantenible,
- DevOps/MLOps responsables de los despliegues, la monitorización y los costes del modelo.
Enchufamos ese equipo a tu producto como refuerzo de equipo o equipo dedicado, bajo tu dirección, sumando competencias justo donde faltan.
¿Cómo lo hacemos en RITS?
Lo hacemos como partner nearshore desde Polonia, con competencia real en AI/Data dentro del RITS Group (incluidos nuestros equipos de AI/LLM/datos). Empezamos por una funcionalidad medible, no por toda una plataforma de IA de golpe. La construimos sobre RAG y los datos propios del cliente, con evaluación y monitorización desde el principio, no solo tras las primeras quejas. Fijamos la privacidad y la seguridad del dato antes de la primera llamada al modelo, porque en proyectos regulados deciden si una funcionalidad sale. Hemos entregado proyectos de GenAI/RAG/LLM, entre ellos un asistente de conocimiento basado en IA para un cliente del sector seguros, y llevamos esa experiencia a los productos tecnológicos, cubriendo con gente contrastada los roles que faltan.
¿Por dónde empezar a añadir funciones de IA a un producto?
Empieza por un problema concreto de usuario que puedas medir y por la pregunta de qué conocimiento necesita la IA para responder con sentido. Eso decide si te hace falta un LLM a secas o RAG, qué datos tienes que preparar y qué roles cubrir. Si estás valorando con qué modelo de colaboración arrancar, explicamos las diferencias en nuestro artículo sobre modelos de colaboración en TI.
¿Vas a añadir funciones de IA (LLM/RAG) a tu producto? Hablemos - ajustamos las competencias y la arquitectura a tu caso.