Trabajar con un equipo de AI Engineering sin ser ingeniero

Lo que no tienes que hacer

Empecemos quitando una presión innecesaria. No tienes que elegir un modelo, arbitrar entre dos enfoques de recuperación de información, evaluar una arquitectura ni juzgar la calidad de una implementación. Esas decisiones son del equipo, y asumirlas produce el peor escenario: una solución impuesta desde fuera de la que sigues respondiendo ante el negocio.

En cambio, nadie hará por ti el trabajo de definir el problema, decir qué es aceptable, aportar casos reales y zanjar los arbitrajes de negocio. Un equipo de AI Engineering privado de esos elementos los inventa, y los inventa mal: no por incompetencia, sino porque no tiene acceso al terreno.

La frontera correcta no es «negocio por un lado, técnica por otro». Es: tú describes qué debe ser cierto, el equipo decide cómo hacerlo cierto, y discutís juntos cuánto cuesta.

Llegar con un problema, no con una solución

La petición llega casi siempre ya vestida de solución. Circula por la organización en forma técnica, a menudo copiada de una demo vista en otro sitio, y cierra la conversación antes de que empiece.

La segunda versión no exige competencia técnica alguna. Y sin embargo contiene todo lo que el equipo necesita: la necesidad, los usuarios, la naturaleza de los datos, las restricciones, los riesgos y el inicio de un criterio de éxito. Además deja abierta la posibilidad de que algo mucho más simple que un agente resuelva el problema.

Reformular una petición que ya llega como solución

Cuando la petición llega en forma técnica — y llegará — la reformulación cabe en seis preguntas, hechas sin hostilidad: qué trabajo humano queremos aligerar, quién lo hace hoy, con qué datos, qué acciones podría emprender el sistema, qué sería grave y cómo sabremos que funciona. Son los seis ángulos que el equipo necesitará de todos modos.

Describir el comportamiento esperado

En un sistema de IA, la especificación no puede enumerar todas las entradas posibles. Describe un comportamiento: qué hace el sistema en situación normal, qué hace cuando no está seguro, qué no hace nunca. Esa descripción no tiene que ser técnica, pero sí observable: alguien debe poder mirar una salida y decir si respeta la regla.

• Alcance: qué casos se tratan, cuáles se excluyen explícitamente y si la exclusión es visible para el usuario.
• Comportamiento nominal: qué produce el sistema, en qué formato, con qué referencias o justificaciones.
• Comportamiento ante la duda: abstenerse, dar una respuesta parcial, pedir una precisión, escalar a una persona.
• Prohibiciones absolutas: lo que el sistema no debe producir nunca, pase lo que pase.
• Lugar del control humano: en qué punto del recorrido, por parte de quién y con qué información para decidir.

Errores aceptables y errores inaceptables

Es la aportación más útil de un perfil de negocio y la que más se olvida. Ningún sistema de IA está libre de errores; la pregunta no es «cuántos» sino «cuáles». Un equipo técnico no puede zanjarlo por ti: depende del riesgo de negocio, del contrato, de la relación con el cliente y a veces de la regulación.

• Error aceptable: una respuesta incompleta que el usuario detecta al instante y corrige sin coste.
• Error caro: una respuesta plausible pero falsa, que el usuario no puede distinguir de una buena.
• Error inaceptable: un compromiso, una promesa, un dato personal expuesto, una decisión presentada como validada sin serlo.
• Una asimetría asumida: a menudo es preferible que el sistema calle diez veces sin motivo a que afirme una vez sin fundamento.

Formular esas tres categorías transforma de inmediato la conversación técnica: orienta las salvaguardas, los umbrales, el lugar del control humano y el comportamiento del sistema ante la incertidumbre.

Aportar casos reales, también los incómodos

Un conjunto de casos reales es lo más valioso que aporta un perfil de negocio y, a menudo, lo único que el equipo no puede producir solo. Veinte casos del terreno valen más que un documento de especificación de veinte páginas, porque contienen ambigüedades que nadie habría pensado en escribir.

• Casos ordinarios, representativos del volumen diario.
• Casos incómodos: peticiones mal formuladas, información ausente, varias preguntas en una sola.
• Casos límite: situaciones raras pero de alto impacto, donde el error sale caro.
• Casos fuera de alcance, para comprobar que el sistema los rechaza con limpieza.
• Para cada caso, cuál habría sido una buena respuesta humana: esa referencia es la que hace posible la evaluación.

Estos casos deben anonimizarse y respetar las reglas de tratamiento de datos de la organización. Es un punto que se resuelve al principio, no cuando el equipo está esperando el conjunto de pruebas.

Participar en la definición de la evaluación

La evaluación es el punto de encuentro entre negocio e ingeniería. El equipo sabe medir, comparar dos versiones y automatizar comprobaciones. Lo que no sabe es qué cuenta: qué desviación es tolerable, qué dimensión prima sobre las demás, qué umbral autoriza una puesta en producción.

• Decir qué significa «buena respuesta» en tu ámbito, sobre ejemplos concretos y no en abstracto.
• Jerarquizar: exactitud, exhaustividad, tono, formato, rapidez; no todo puede ser prioritario.
• Fijar umbrales con el equipo: qué desencadena una puesta en producción y qué desencadena una vuelta atrás.
• Aceptar revisar salidas: una revisión humana periódica sobre una muestra sigue siendo la medida más fiable al inicio.
• Prever la repetición: la evaluación no es un hito, es un dispositivo que se reejecuta en cada cambio.

Prototipo y producción: dos conversaciones distintas

Muchas tensiones nacen de un malentendido sobre el estatus de lo que se enseña. Una demo lograda demuestra que un comportamiento es posible en casos elegidos. No dice nada sobre la estabilidad en casos no elegidos, el coste a volumen real, el comportamiento ante la caída de una dependencia o la carga de mantenimiento.

El papel de un perfil de producto o proyecto es nombrar esa diferencia cuando todavía sale gratis: antes de que la demo se haya presentado a un comité que la tomará por una entrega. La pregunta no es «¿cuándo está listo?», sino «¿qué falta entre lo que enseñáis y algo que nuestros usuarios puedan usar sin nosotros?».

Entender las dependencias de datos sin convertirse en Data Engineer

La calidad de un sistema de IA depende ante todo de aquello a lo que accede. No tienes que entender los pipelines, pero hay preguntas que son de negocio y que nadie más puede responder.

• Qué fuentes hacen falta, quién es su responsable y en qué condiciones pueden usarse.
• Con qué frecuencia cambian y en qué se convierte una respuesta basada en una versión caducada.
• Quién puede ver qué: un asistente nunca debe ampliar los permisos de su usuario.
• Qué falta: la información que las personas conocen pero que no está escrita en ningún sitio.
• Qué se conserva, durante cuánto tiempo y qué puede exponerse a un tercero.

Discutir latencia, coste y calidad como un arbitraje de producto

Las tres dimensiones están ligadas: mejorar la calidad suele alargar el tiempo de respuesta y aumentar el coste por uso. Un equipo técnico puede describir las opciones; no puede decidir solo cuál sirve mejor a los usuarios. Es un arbitraje de producto, y nombrarlo como tal evita que se zanje por defecto.

• Latencia: qué demora sigue siendo aceptable en el recorrido real, no de media sino en el peor caso habitual.
• Coste: qué coste por uso se sostiene si el volumen se duplica y quién vigila esa evolución.
• Calidad: a partir de qué nivel el servicio es útil y a partir de cuál el esfuerzo adicional ya no aporta nada al usuario.
• Qué se acepta sacrificar primero si las tres no son alcanzables a la vez.

Qué corresponde a producto y qué a ingeniería

Una frontera explícita elimina la mayor parte de las fricciones. Conviene fijarla una vez, al principio, en lugar de renegociarla en cada desacuerdo.

• Producto: el problema, los usuarios, el alcance, el comportamiento esperado, las prohibiciones, las prioridades, los umbrales de aceptación y el lugar del control humano.
• Ingeniería: la arquitectura, la elección de componentes, la estrategia de recuperación de información, la implementación de la evaluación, el rendimiento y la explotación.
• Entre ambos: qué se mide, el arbitraje calidad / latencia / coste, el troceado en versiones y la decisión de puesta en producción.
• Nadie: lo que no está escrito en ningún sitio acaba zanjado de forma implícita, casi siempre en el peor momento.

Documentar decisiones, no conversaciones

En un proyecto de IA, el comportamiento del sistema resulta de una acumulación de pequeñas decisiones: un alcance recortado aquí, un umbral elevado allá, un caso descartado por poco frecuente. Seis semanas después nadie recuerda por qué y la pregunta vuelve idéntica.

Basta con una traza corta: la decisión, la fecha, el motivo y lo que se aceptó perder. Ese documento no es un trámite administrativo: es lo que permite responder a un usuario que cuestiona un comportamiento y evitar repetir tres veces el mismo debate.

Las preguntas que conviene hacer en una revisión

Una buena pregunta en revisión no trata de la implementación. Trata de lo que se ha decidido de forma implícita y de qué pasará cuando la situación no sea ideal.

• ¿En qué casos habéis visto que el comportamiento se degrada?
• ¿Qué hace el sistema cuando la información no existe en las fuentes?
• ¿Qué ha cambiado desde la versión anterior y cómo sabemos que es mejor?
• ¿Qué casos hemos decidido no tratar y es visible para el usuario?
• ¿Qué es lo que más os preocupa si ponemos esto ante usuarios reales?
• ¿Qué necesitáis de nuestro lado para avanzar?
• ¿Qué depende de un proveedor externo y qué ocurre si lo cambia?

La última pregunta — «¿qué necesitáis de nuestro lado?» — es la que más desbloquea. Hace aparecer aquello que el equipo lleva tres semanas esperando sin haberlo pedido formalmente.

Evitar el micromanagement técnico

La línea es fácil de enunciar: cuestionar un resultado es legítimo, prescribir una implementación no lo es. Preguntar por qué el sistema responde así en tres casos concretos es una contribución; sugerir cambiar de modelo, ajustar una formulación o añadir una etapa técnica es una intrusión, incluso con buena intención.

Queda un caso en el que insistir está justificado: cuando no entiendes un comportamiento del que responderás ante el negocio. Pedir una explicación adicional no es micromanagement, es una condición para ejercer tu papel. La formulación que funciona es directa: «necesito poder explicar este comportamiento a un usuario; ¿puedes reformulármelo en términos que yo pueda reutilizar?».

Un equipo de AI Engineering trabaja mejor con un interlocutor de producto que hace preguntas difíciles sobre el comportamiento que con uno silencioso que descubre el resultado en producción. La colaboración no exige competencias de ingeniería; exige precisión, casos reales y una frontera clara.

• AI Engineering
• Evaluación
• AI Product