criterio · 6 min de lectura
El prompt no es el problema: la IA necesita contexto del negocio
Una IA puede redactar bien y aun así sumar trabajo si cada persona debe reconstruir a mano el contexto. Qué información, reglas y estado necesita un sistema para operar con criterio.
Una empresa prueba un asistente comercial para redactar seguimientos, resumir conversaciones y preparar respuestas. La demo funciona. En la operación real aparece otro trabajo: antes de pedirle algo a la IA, cada vendedor tiene que copiar la última conversación, explicar en qué etapa está la oportunidad, aclarar qué producto interesa, recordar el descuento permitido y contar qué se prometió en la reunión anterior.
La respuesta puede ser buena y aun así el sistema no haber automatizado casi nada. El trabajo de reconstruir el contexto sigue dependiendo de una persona. El cuello de botella cambió de lugar: ya no está en redactar, sino en reunir información, verificar qué está vigente y decidir qué datos necesita la IA para no responder a ciegas.
Por eso, en NexOps usamos una regla simple: para IA aplicada a una empresa, el contexto suele valer más que el prompt. Un prompt explica qué queremos hacer. El contexto permite saber sobre qué realidad concreta hay que hacerlo.
El síntoma: prompts cada vez más largos
Cuando una solución necesita instrucciones enormes para funcionar, muchas veces estamos usando el prompt como sustituto de un sistema que todavía no existe. La persona termina escribiendo en cada interacción lo que el software debería poder conocer por diseño: datos del cliente, políticas, definiciones, estado del proceso, responsables, límites y excepciones.
Si ese esfuerzo no está integrado al flujo, la empresa sigue dependiendo de memoria individual, copiar y pegar, documentos dispersos y reuniones para reconstruir qué está pasando.
Qué significa contexto en una empresa
Contexto no es cargar todos los archivos de la compañía en una ventana de chat. Es darle al sistema la información correcta, vigente y autorizada para la tarea que tiene que resolver.
- Estado: en qué punto está el proceso ahora, qué ocurrió antes y cuál es la próxima acción esperada.
- Datos: cliente, operación, producto, inventario, ticket, contrato o cualquier registro que sea fuente de verdad para esa decisión.
- Reglas: políticas comerciales, criterios de aprobación, SLA, excepciones y condiciones que una persona consulta antes de actuar.
- Permisos: qué puede leer, qué puede modificar y qué acciones requieren revisión humana.
- Memoria útil: decisiones previas, compromisos, preferencias o antecedentes que cambian la respuesta correcta.
- Evidencia: de dónde salió cada dato y cómo verificar después por qué el sistema tomó una decisión.
OpenAI usa la idea de Business Context para conectar agentes con sistemas de registro como CRM, aplicaciones internas y repositorios de datos. Anthropic incluye dentro del contexto instrucciones, herramientas, datos externos e historial. Las dos miradas apuntan al mismo problema operativo: una IA aislada del estado real del negocio tiene que adivinar o pedir que una persona se lo reconstruya.
Un ejemplo: seguimiento comercial
Supongamos que un lead pidió una propuesta hace cinco días. El CRM muestra que la propuesta fue enviada, hubo una objeción por plazo de entrega y el vendedor acordó volver a contactar hoy. Además, la política comercial permite cierto rango de descuento sin aprobación y el sistema de stock indica disponibilidad parcial.
Con sólo un prompt como “redactá un seguimiento para este cliente”, la IA no conoce nada de eso. El vendedor tiene que contárselo. Con contexto conectado, el sistema puede preparar un mensaje coherente con la etapa, recuperar el compromiso pendiente, evitar ofrecer algo fuera de política y señalar que la disponibilidad necesita confirmación antes de prometer una fecha.
El valor no está en que el texto suene mejor. Está en reducir reconstrucción manual, olvidos y decisiones inconsistentes. Y si el sistema registra después qué acción se tomó, el CRM deja de ser un archivo pasivo y se vuelve parte del circuito operativo.
Cómo armar un pipeline de ventas que funcione como sistema operativo comercial
Más contexto tampoco significa mejor contexto
El extremo opuesto también falla: conectar todo y esperar que el modelo encuentre solo qué importa. Datos viejos, documentos contradictorios, notas sin dueño y herramientas con definiciones distintas pueden empeorar la respuesta.
El diseño debería responder tres preguntas: cuál es la fuente de verdad para cada dato, qué información necesita esta tarea y qué tan actual debe estar. A veces el contexto correcto es una consulta puntual al CRM. Otras veces es una política aprobada, una vista de stock o el último intercambio con el cliente. El objetivo no es maximizar cantidad de información; es reducir ambigüedad.
Un sistema conectado puede recuperar contexto justo cuando lo necesita; un chat aislado obliga a la persona a convertirse en integrador humano de datos.
Contexto sin límites también es un riesgo
Conectar datos no implica habilitar acceso irrestricto. El contexto tiene que respetar permisos, alcance y sensibilidad. Un agente de ventas puede necesitar leer actividad comercial, pero no por eso debería acceder a información financiera completa. Un asistente de soporte puede consultar historial de tickets sin tener permiso para modificar condiciones contractuales.
OpenAI, en su guía práctica de agentes, separa herramientas para recuperar información de herramientas que ejecutan acciones y recomienda operar dentro de guardrails definidos. Para una empresa, esa separación es clave: saber algo y estar autorizado a actuar sobre ese dato son dos capacidades distintas.
Dónde conviene poner límites a un agente de IA
El criterio NexOps: diseñar el sistema antes que el prompt
En NexOps priorizamos sistemas antes que herramientas. Aplicado a IA, eso significa que antes de discutir cuál modelo escribe mejor conviene entender qué proceso queremos mejorar, qué información usa hoy una persona para resolverlo y dónde vive esa información.
Si la respuesta es “depende de quién esté trabajando”, “está en varios chats” o “lo sabemos de memoria”, el problema todavía no es el modelo. Hay una deuda de contexto. Resolverla puede implicar ordenar el CRM, definir una fuente de verdad, documentar reglas, integrar sistemas o registrar decisiones que hoy quedan fuera del proceso.
Ese trabajo no es previo a la IA en un sentido burocrático. Es parte de la solución. Cuanto menos tenga que reconstruir una persona antes de cada interacción, más capacidad real puede absorber el sistema.
Cinco preguntas antes de implementar
- ¿Qué consulta hoy una persona antes de tomar esta decisión o ejecutar esta tarea?
- ¿Qué sistema o documento es la fuente de verdad para cada dato importante?
- ¿Qué información cambia con frecuencia y debe recuperarse en tiempo real o casi real?
- ¿Qué reglas, excepciones y permisos limitan una respuesta o acción válida?
- ¿Qué debería quedar registrado para que otra persona pueda revisar después qué ocurrió?
Si estas respuestas están claras, recién entonces tiene sentido optimizar instrucciones, elegir herramientas y decidir cuánto grado de autonomía conviene. Si no están claras, perfeccionar el prompt puede mejorar una demo, pero difícilmente resuelva la operación.
La métrica correcta no es cuánto sabe la IA
Una buena implementación no debería obligar a las personas a preparar manualmente cada consulta para que el modelo parezca inteligente. Debería reducir pasos, recuperar información confiable cuando hace falta, sostener reglas y dejar trazabilidad.
El impacto aparece cuando el equipo necesita menos memoria para operar, menos reuniones para reconstruir estados, menos copiar y pegar entre sistemas y menos tiempo para llegar a una decisión. Ahí la IA deja de ser una capa de redacción y empieza a formar parte de un sistema de trabajo.