Tenemos equipo de sistemas pero no especialista en IA: cómo se reparte el trabajo

Mes dos, jueves a la tarde, un mensaje en el grupo del proyecto: «el bot le contestó cualquiera a un cliente». Sistemas revisa y puede demostrar que el flujo corrió completo, sin una sola excepción, exactamente como estaba escrito. La respuesta igual estuvo mal, y la conversación se traba ahí, porque nadie definió antes de arrancar quién se hace cargo de esa clase de pregunta.

La línea de corte que evita ese jueves no pasa por lo técnico ni por lo difícil: pasa por si la respuesta correcta se conoce de antemano. Tu equipo de sistemas se queda con todo lo que tiene una respuesta conocida y verificable —accesos, infraestructura, seguridad, integraciones, ventana de despliegue—. El especialista se queda con lo único que no se valida leyendo código: el comportamiento del modelo.

Repartido así, sistemas no queda de espectador, porque conserva el veto sobre producción y sobre los datos, ni de cuello de botella, porque no tiene que aprender a escribir prompts ni a evaluar respuestas para que el proyecto avance. Abajo está la tabla con las doce decisiones concretas, quién decide y quién ejecuta cada una, los tres accesos que hay que dar y el que nunca, y la prueba de tres preguntas para clasificar la decisión trece: la del jueves, la que no está en la tabla.

La línea de corte es determinístico contra probabilístico, no técnico contra no técnico

El error clásico es repartir por conocimiento técnico: "esto es difícil, lo hace el de afuera". Ese criterio no divide nada, porque tu equipo de sistemas casi siempre entiende más de tu operación que cualquier proveedor recién llegado.

El criterio que sí divide es la naturaleza de la respuesta. Tu equipo sabe contestar por qué falló el proceso de las 3 de la mañana: lee el log, encuentra el error, lo arregla. Hay una respuesta correcta y está escrita. Nadie contesta de la misma forma por qué el bot le respondió eso a ese cliente, porque no hay log que lo diga. El flujo se ejecutó perfecto, devolvió 200, no hubo excepción, y la respuesta igual estuvo mal. Lo que hay atrás es un prompt, un conjunto de documentos, una forma de recuperarlos y un modelo que puede contestar distinto la semana que viene sin que nadie haya tocado nada.

Esa es la frontera. Todo lo que se verifica leyendo código o mirando un tablero de errores es de sistemas. Todo lo que solo se verifica leyendo cien conversaciones reales es del especialista. Repartir por ahí evita el desenlace que nadie firmó: sistemas queda como responsable formal de una cosa que no tiene forma de auditar.

La tabla: doce decisiones, quién decide y quién ejecuta

Esto es lo que hay que llenar antes de la primera reunión técnica. Poné nombre y apellido en cada celda, no áreas.

Tres cosas que se leen mal a primera vista y son las que hacen que la tabla funcione.

Sistemas decide cinco de las doce y ejecuta cuatro. No es un rol de acompañamiento: es el único que puede parar un despliegue. Si tu jefe de sistemas mira esta tabla y no ve poder real, revisá si le sacaste el veto sobre producción, porque ahí es donde vive.

El negocio decide seis y propone una séptima. Casi todas las decisiones que definen si el proyecto sirve —qué se responde, qué no, cuándo interviene una persona, qué se mide— no son técnicas. Cuando esas celdas quedan vacías o dicen "IT", el proyecto termina siendo una demo que nadie usa.

El especialista ejecuta ocho y decide una sola: qué modelo se usa y con qué configuración. Es deliberado. Un proveedor que además decide qué preguntas rechaza tu bot está tomando decisiones comerciales sin tu contexto.

La tabla se manda llena antes de la primera reunión, no se presenta adentro de ella: el reparto se resiente cuando se descubre a mitad de camino, nunca cuando se anuncia antes. Tres cosas hay que decir al mandarla, y ninguna necesita más de una línea. Que las cinco filas de sistemas no se tocan sin su ok, veto sobre producción incluido. Que el prompt, los documentos y la evaluación de las respuestas no se le van a sumar a la carga. Y que lo que necesitás de vuelta son definiciones con fecha —qué ambiente, con qué usuario, quién de su equipo entra a la reunión semanal—, no un informe.

Los tres accesos que hay que dar y el que nunca

Sistemas va a tener que dar acceso a datos propios. Lo que se negocia no es si se da: es la forma.

• Un usuario de servicio nominado, con vencimiento. Propio del flujo, con fecha de corte a 90 días renovable. Si el proyecto se cae o el proveedor cambia, el acceso muere solo.
• Lectura sobre una vista o una réplica, no sobre producción. Con los campos que el flujo realmente usa. Un bot que responde stock y precio no necesita ver margen ni costo de compra. Definir esa lista lleva diez minutos y es lo que evita la discusión de después, cuando alguien descubre que el modelo tenía el costo a la vista.
• Un ambiente de prueba con datos anonimizados para las primeras dos semanas, que es cuando más se rompe.

El que no se da: administrador sobre producción. Si el pedido inicial del proveedor es ese, no es una señal de que sabe mucho, es una señal de que va apurado.

La decisión trece: la prueba de tres preguntas

La tabla cubre las doce decisiones que se pueden anticipar. La que rompe el reparto es la trece, y no llega en una reunión: llega un martes como un mensaje suelto de cuatro palabras, "el bot contestó cualquiera", que alguien tiene que reenviar a algún lado. Si esa clasificación se hace por intuición, en dos semanas volvés al criterio que no divide nada: esto parece difícil, mandáselo al de afuera.

Tres preguntas en orden. La primera que da un sí cierra el caso, y las puede aplicar en treinta segundos quien recibe el mensaje, sin saber nada de IA.

1. ¿Existe una respuesta correcta escrita en algún lado desde antes? Una lista de precios vigente, un horario, un permiso, un límite de la cuenta del proveedor. Si existe y alguien la puede abrir y leer, el caso es de sistemas, por más que el síntoma haya llegado hablando del bot.

2. ¿Quedó un error en alguna parte? Un timeout, una excepción, una ejecución que figura fallida, un mensaje que nunca salió. Si la falla dejó rastro es de sistemas, y se arregla como se arregla cualquier otra cosa. Si el rastro no existe —para el sistema no pasó nada raro y lo que está mal es el contenido— es del especialista, y conviene decirlo en voz alta en la reunión de arranque: ese caso no lo va a marcar nunca un tablero de errores, así que si nadie tiene asignado leer, no se detecta.

3. Para saber si quedó bien, ¿hay que leer? Si la verificación es abrir la conversación y juzgar si esa respuesta servía, ejecuta el especialista y decide el negocio, porque "servía" es una definición comercial. Sistemas no puede firmar eso, y pedirle que lo firme es lo que lo deja como responsable de algo que no tiene forma de auditar.

Cuatro casos que llegan con la misma cara y se reparten distinto:

• "El bot no contestó cinco mensajes de ayer a la tarde." Sistemas. Hay ejecuciones fallidas, un servicio caído o un límite de la cuenta: el rastro existe y la respuesta correcta también.
• "El bot dio un precio que ya no existe." Sistemas primero, y casi siempre termina ahí: el número salió de una tabla que se sincroniza cada tanto y llegó tarde. Sólo si el dato estaba bien en origen y el modelo igual dijo otro, el caso cruza al especialista. Es el mismo síntoma con dos dueños posibles, y lo que decide cuál es una consulta a la base, no una opinión.
• "El bot inventó una política de devolución que no tenemos." Especialista y negocio. La pregunta 1 da que no: ese documento no existe, y por eso el modelo completó el hueco. El arreglo no es técnico, es escribir la política que nunca estuvo escrita y meterla en el corpus.
• "Le ofreció un descuento a un cliente." Negocio decide, especialista ejecuta. Parece un error del sistema y es una decisión comercial que nadie tomó: qué puede prometer el asistente y qué tiene que derivar. Si esto lo resuelve sistemas solo, tu política de descuentos la terminó escribiendo el que configuró el prompt.

El caso donde dos personas aplican la prueba y les da distinto es el único que merece ir a la reunión semanal. Los demás se reenvían y listo, que es todo lo que se le pide a un reparto.

Las dos formas en que esto se rompe

La cola. Sistemas dice que sí, el proyecto arranca, y el acceso a la base queda detrás de la migración del ERP y del cierre de mes. Hay algo puntual de los proyectos de IA que empeora esto: el primer pedido a sistemas no es una tarea sino una definición —qué ambiente, sobre qué datos, con qué usuario—, y una definición no tiene tipo de ticket ni estimación, así que queda flotando como "pendiente de charlar". Se resuelve pidiendo una fecha comprometida para esas tres definiciones en la reunión de arranque, no urgencia.

El go-live sorpresa. El asistente sale a producción y sistemas se entera cuando una consulta satura la base un día 3, en pleno cierre. Se resuelve con una sola regla: la ventana de despliegue la fija sistemas, siempre, aunque el flujo no toque nada de ellos.

Las tres capacidades que no se pueden repartir porque todavía no existen

Un reparto de tareas asigna trabajo que alguien ya sabe hacer. La tabla resuelve la convivencia, que es el problema del mes uno, y funciona mientras haya un asistente o dos o tres flujos en producción y las respuestas se puedan revisar leyendo a ojo.

Hay tres capacidades que ninguna celda de la tabla contiene, porque no son tareas sino oficios que tu empresa todavía no tiene adentro, y por eso poner más nombres no las hace aparecer:

1. Cuando hay que decidir si las respuestas son suficientemente buenas. Repartir tareas no crea la capacidad de armar un set de casos de prueba, correrlo cada vez que cambia el prompt o el modelo, y saber si empeoró. Eso es un proceso permanente, no una reunión.
2. Cuando el modelo cambia solo. Los proveedores actualizan y retiran versiones. Un asistente que respondía bien puede empezar a responder distinto sin que nadie de tu empresa haya tocado nada. Acá ni siquiera alcanza con leer una conversación: leída sola, la respuesta nueva parece razonable. Sólo se nota contra las respuestas de antes, y eso exige haberlas guardado.
3. Cuando pasás de uno a cinco flujos. Ahí aparece la pregunta que ningún reparto contesta: por qué este cliente recibió dos mensajes, cuál de los cinco flujos lo mandó, y en qué orden corren.

Ese es el límite real: la tabla ordena quién hace qué con lo que ya sabés hacer. Lo que no se puede repartir es la parte que nadie del equipo sabe hacer todavía, y es exactamente la parte que hace que el asistente siga sirviendo en el mes ocho.

En una línea

Llená la tabla esta semana y usá la prueba de tres preguntas con el primer "contestó cualquiera" que llegue. Si tu equipo de sistemas conserva el veto sobre la ventana de despliegue y no carga con la evaluación de respuestas, el reparto se sostiene solo.

Y agendá una segunda cosa, que es la que casi nadie agenda: dentro de sesenta días, media hora para volver a correr las mismas tres preguntas sobre las mismas conversaciones guardadas. Si las respuestas cambiaron y nadie de tu empresa tocó nada, dejaste de discutir el punto 2 en abstracto y pasaste a tener la prueba adentro de tu propia operación. Esa media hora vale más que la reunión de arranque, y es la única tarea de toda la tabla que no le podés delegar a sistemas ni al proveedor, porque el que decide si una respuesta es aceptable es el dueño del proceso.

Dos decisiones vecinas que esta tabla no contesta y conviene no mezclarle: si conviene poner a alguien adentro en vez de traer a un especialista se resuelve con horas y con plata, y la cuenta a 12 meses está en contratar o tercerizar; lo que hay que dejar cerrado por escrito antes de firmar está en las 12 preguntas para hacerle a un proveedor.

Cuando la tabla esté llena, mandala a info@striqtech.com. Lo que se lee ahí no es qué herramienta elegiste: es cuántas de las doce filas terminaron con el mismo nombre en las dos columnas.