Consultoría de IA remota: cómo acordar el trabajo y la entrega

En un encargo remoto, una revisión puede quedarse parada porque nadie sabe quién debe responder. El código está listo, pero la persona que conoce el proceso del cliente no ha visto los ejemplos. Otra reunión de seguimiento no resuelve esa falta de responsabilidad.

Antes de empezar una integración o revisión de IA, acuerda cómo circularán las preguntas y quién aceptará el resultado. Ese acuerdo permite trabajar entre Europa y Latinoamérica sin depender de que todo el equipo esté conectado a la vez.

Un acuerdo de trabajo breve

No hace falta convertirlo en un manual extenso. Debe bastar para que una pregunta tenga destinatario y un bloqueo quede registrado. La franja de coincidencia se pacta con las personas concretas; «trabajo internacional» no significa atención permanente.

Preparar el material que permite avanzar

Un brief útil describe qué hace hoy el sistema y qué debería cambiar. Añade un ejemplo representativo, los fallos que ya conoces y las restricciones de acceso. Si todavía no existe código, explica qué decisión necesitas tomar antes de construirlo.

Los ejemplos pueden empezar con datos ficticios o debidamente preparados para compartir. Si una comprobación exige datos reales, primero hay que acordar el acceso y la forma de tratarlos con la persona responsable del sistema.

Las credenciales se entregan por el mecanismo aprobado para el proyecto. La guía de gestión de secretos de OWASP sirve de referencia para revisar acceso, almacenamiento y retirada de credenciales. No incluyas claves en el brief ni en capturas de errores.

Revisar algo que se pueda abrir

Un avance útil puede ser una pull request, una ejecución grabada con entradas conocidas o una nota de arquitectura que permita comparar dos opciones. Debe decir qué está listo para revisar y qué falta por comprobar.

En una función de IA, conviene que el cliente vea también resultados rechazados o incompletos. Si solo se comparte el ejemplo que salió bien, quien revisa no puede decidir cómo debería tratar el producto los demás casos.

Reserva la conversación en directo para los desacuerdos que necesiten una decisión conjunta. Después, deja escrito qué se eligió y qué consecuencia tiene. Así la siguiente persona que entra al proyecto puede continuar sin reconstruir la reunión.

Aceptación y cambios de alcance

Para una entrega concreta, prepara los ejemplos y el criterio de aceptación antes de desarrollarla. Una muestra que el cliente aporta tarde puede descubrir un requisito nuevo; registrar cuándo cambió evita discutir si ya estaba incluido.

Si aparece un problema fuera del alcance, descríbelo con sus efectos. Se puede resolver en una ampliación, dejar documentado o acordar que impide continuar. El trabajo adicional se define antes de asumirlo.

Entregar para que otro pueda continuar

El traspaso debe permitir que la persona responsable ejecute y revise el trabajo. Pide el código en el repositorio acordado, instrucciones de configuración sin secretos y las pruebas utilizadas. Incluye los límites conocidos. Si el plan de despliegue prevé volver a una versión anterior, documenta cómo hacerlo.

También conviene identificar las cuentas del proveedor y quién conserva su control. El fin del encargo debe cerrar o ajustar los accesos concedidos. Mantenimiento, nuevas versiones y atención posterior se acuerdan por separado.

Pharosyne ofrece colaboración remota desde Madrid para equipos de Europa, Latinoamérica y otros lugares. Al proponerme un encargo, dime qué necesitas entregar, dónde está el equipo y quién recibirá el trabajo. Si todavía estás decidiendo qué tipo de ayuda contratar, empieza por la guía para definir el encargo de IA.