En la reciente edición de AquaSur 2026, nuestro CTO, Abdías Ponce, compartió una idea central sobre el uso de inteligencia artificial: el rendimiento de estos sistemas no depende únicamente del modelo, sino del contexto en el que se utilizan. Un modelo puede tener alta capacidad técnica, pero sin información suficiente sobre el proceso, las restricciones y el objetivo, su respuesta será incompleta. La diferencia no está en acceder a IA, sino en cómo se integra en la operación.
Los modelos de lenguaje no entienden procesos productivos ni criterios de negocio. Generan respuestas en función del contexto entregado. Por eso, ante una misma tarea, el resultado puede variar significativamente dependiendo de cómo se formula la solicitud.
Una forma práctica de reducir esa variabilidad es estructurar el prompt bajo cinco dimensiones:
rol + contexto + tarea + formato + restricciones
Un ejemplo concreto en planta de proceso: ante el objetivo de analizar un reporte de producción para evaluar la eficiencia e identificar cuellos de botella, un prompt típico sería "Resume este documento". El resultado será descriptivo, pero no necesariamente útil para la toma de decisiones.
Si en cambio se estructura así: "Actúa como un ingeniero de procesos con 20 años de experiencia en salmonicultura. Analiza este documento que resume la eficiencia de una planta de proceso y, a partir de este análisis, identifica los tres principales cuellos de botella. Preséntalos en una tabla que incluya problema, impacto y solución sugerida, considerando exclusivamente soluciones de rápida implementación que no requieran una inversión superior a $50.000 USD", el modelo recibe un rol técnico específico, un contexto productivo claro, una tarea concreta, un formato de salida definido y restricciones operacionales reales. El resultado deja de ser un resumen y pasa a ser un insumo directo para la operación.
El chain of thought es una técnica que consiste en pedirle explícitamente al modelo que descomponga un problema en etapas antes de entregar una conclusión. No busca una respuesta más larga, sino una respuesta estructurada. En contextos como la salmonicultura, donde las decisiones dependen de múltiples variables, esto permite evitar simplificaciones incorrectas.
Por ejemplo, al evaluar una estrategia de alimentación en un centro de cultivo, un prompt directo como "¿Cuál es la mejor estrategia de alimentación para este centro?" tiende a generar respuestas genéricas. En cambio, estructurar el análisis en cinco pasos —evaluar variables biológicas, analizar variables ambientales, identificar restricciones operacionales, comparar alternativas de estrategia y concluir con una recomendación justificada— lleva al modelo a seguir un proceso de análisis. Esto permite entender cómo llega a la recomendación y evaluar si es consistente con la realidad operativa.
El few-shot learning consiste en entregar ejemplos dentro del prompt para que el modelo entienda cómo debe responder. No se entrena el modelo, pero se ajusta su comportamiento en base a patrones. Esto es útil cuando el problema no es la falta de información, sino la falta de consistencia en los criterios.
Un caso típico en planta de proceso: se quiere clasificar eventos productivos según su criticidad. Un prompt básico como "Clasifica estos eventos según su criticidad" puede variar dependiendo de cómo el modelo interprete cada caso. Si en cambio se incorporan ejemplos —parada total de línea por falla eléctrica como crítico, desviación de color fuera de rango en 5% del lote como medio, leve aumento de defectos sin impacto en clasificación final como leve— el modelo no solo responde, sino que replica el estándar entregado, lo que permite mayor consistencia entre equipos y decisiones.
El enfoque de RAG (Retrieval-Augmented Generation) permite que un modelo de lenguaje no dependa únicamente de conocimiento general, sino que incorpore información específica de la empresa antes de generar una respuesta. En términos simples, RAG toma información desde distintas fuentes, la traduce a un formato común y la pone a disposición del modelo como contexto.
Un caso concreto: entender cuáles fueron los factores de pérdida de calidad de una semana en una planta de proceso de salmón. La dificultad no está en la pregunta, sino en dónde está la información. En una planta de proceso, los datos relevantes están distribuidos en múltiples áreas: calidad (reportes de defectos, color, calidad final), producción (velocidad de línea, rendimiento, conteo de filetes), comercial y RRHH (turnos, dotación, pedidos urgentes) e infraestructura (configuraciones de red, sistemas, soporte).
Cada una de estas fuentes usa estructuras distintas y responde a objetivos diferentes. Sin un mecanismo que las integre, el análisis depende de cruzar información manualmente. Lo que hace RAG es intermediar ese proceso: toma estas fuentes heterogéneas, las transforma a un lenguaje común y, al momento de la consulta, recupera la información relevante de cada área como contexto unificado. La condición para que esto funcione sigue siendo la misma: los datos deben existir, estar accesibles y tener trazabilidad.
Un agente es un sistema que interpreta información, toma decisiones y ejecuta acciones sobre otros sistemas. Esto es posible porque el modelo se conecta con herramientas externas (ERP, sistemas productivos, software interno) y actúa directamente sobre ellas.
Un ejemplo concreto en una planta de proceso de salmón: se está operando a máxima capacidad y, en tiempo real, comienza a detectarse una caída de calidad en un lote —por ejemplo, aumento de melanosis. En un flujo tradicional, esto implica detección del problema, validación manual, coordinación entre calidad, producción y comercial, ajustes en sistemas y, finalmente, la definición del destino del producto.
En un enfoque multiagente, ese mismo escenario se resuelve como un flujo integrado: un primer agente analiza los datos de calidad en línea y detecta la desviación; un segundo agente ejecuta la decisión operativa, deteniendo la asignación original y redirigiendo automáticamente el lote a otro destino productivo; en paralelo, un tercer agente evalúa el impacto comercial e identifica alternativas disponibles.
La diferencia no está en el análisis, sino en que la decisión se ejecuta directamente sobre la operación. Esto reduce tiempos de reacción, elimina pasos intermedios y estandariza respuestas ante eventos recurrentes.
Abdías Ponce — CTO, Lythium
Las herramientas para trabajar con IA ya están disponibles. Prompting, chain of thought, few-shot, RAG y agentes no son tecnologías nuevas, sino formas de estructurar el uso de modelos dentro de procesos reales.
La diferencia entre quienes están capturando valor y quienes no, no está en el acceso a la tecnología, sino en cómo definen sus problemas y cómo integran la IA en la operación. Y esas siguen siendo capacidades humanas.
El foco, entonces, está en cómo se incorpora la IA en el trabajo diario: qué contexto se le entrega, cómo se estructuran las solicitudes y a qué información tiene acceso. El cambio relevante es dejar de usar la IA como una herramienta transaccional y empezar a trabajar con ella como una compañera de trabajo. No como un reemplazo, sino como un componente más dentro de la operación.
Entregamos un servicio ágil y de calidad que construye relaciones de largo plazo
¿Buscas ayuda? Hablemos