Cómo organizar la arquitectura de IA de un producto
Separa interfaz, datos, modelo, herramientas y observación. Un ejemplo de clasificación de incidencias muestra dónde validar y controlar acciones.
Un botón “resumir con IA” parece una integración pequeña. Aun así, alguien debe decidir qué datos se envían, dónde se guarda la respuesta, qué ocurre si tarda y cómo se corrige un resumen equivocado. La arquitectura empieza ahí, antes de elegir bibliotecas.
Imagina un SaaS de soporte que sugiere categoría y prioridad para nuevas incidencias. La primera versión puede presentar una propuesta al equipo sin cambiar el registro automáticamente. Esa decisión reduce las acciones que deben controlarse.
Sigue una solicitud completa
La interfaz pide la clasificación e indica si está esperando, ejecutándose o terminada. El backend comprueba el acceso a la incidencia, reúne los datos necesarios y llama al modelo. La respuesta se valida antes de convertirse en una sugerencia utilizable.
Si el modelo devuelve una categoría inexistente, un formato incorrecto o una explicación sin respaldo, el sistema debe tratarlo. Una llamada API exitosa no convierte su contenido en datos válidos del negocio.
Separa sugerencia y ejecución
Al aceptar una propuesta, la actualización debe pasar los mismos permisos y comprobaciones que una edición manual. El servidor conserva las reglas del negocio. Una instrucción escrita dentro de la incidencia no puede conceder más acceso.
Si después incorporas un agente con herramientas, ofrece operaciones pequeñas y claras. La guía de herramientas de Anthropic recomienda empezar con operaciones definidas y evaluarlas en tareas concretas. Consultar disponibilidad resulta más controlable que permitir cualquier consulta.
Incluye la espera y la repetición
La clasificación puede tardar más de lo esperado. Muestra el estado y permite seguir trabajando. Para tareas largas, considera ejecución en segundo plano con un identificador para consultar el resultado, en lugar de dejar la página esperando sin límite.
Define tiempos y número de intentos. Una solicitud repetida no debe crear resultados competidores sin indicar cuál vale. Si una herramienta produce efectos externos, registra la ejecución para no repetirlos al recuperar un fallo.
Observa lo que la persona consigue terminar
Registra modelo, configuración, duración, errores de validación, uso y coste cuando estén disponibles. Evita que los registros sean una segunda copia indiscriminada de los datos del cliente. Conserva lo necesario para investigar y evaluar.
Mide también aceptación y correcciones. Un resumen rápido puede añadir trabajo si obliga a revisar todo el historial. La medida útil incluye ese esfuerzo, además del tiempo de la API.
Añade componentes con una razón
La búsqueda documental, las colas, el almacenamiento vectorial y varios modelos pueden ayudar. Cada componente debe resolver un problema observado y tener responsable de mantenimiento. Para clasificar incidencias, empieza por el flujo mínimo que permita medir calidad y corregir fallos.
Usa la evaluación de modelos para SaaS para elegir la generación. Antes de ampliar acciones, revisa los límites y responsabilidades de agentes.
Sobre el autor
Tiago F SantiagoComentarios
Todavía no hay comentarios
Comparte una pregunta o una experiencia relacionada con el artículo.
Artículos relacionados
