← Volver al blog

El problema de la transferencia: lo que tu equipo debe poseer antes de que vayan los consultores

La mayoría de los proyectos de IA no fracasan al lanzamiento, sino seis meses después, cuando nadie dentro de la empresa puede cambiar el sistema. Aquí tienes cómo evitarlo.

¿Qué significa realmente la propiedad?

La propiedad no es una carpeta de documentos entregada al final del proyecto. Se trata de cuatro capacidades prácticas dentro de tu empresa:

  • Puedes operar el sistema: alguien sabe cómo comprobar si funciona correctamente hoy y recibe notificaciones cuando algo falle.
  • Puedes modificarlo: alguien puede ajustar una regla, añadir una fuente de documentos o actualizar un prompt sin tener que abrir un ticket de soporte.
  • Puedes evaluarlo: alguien puede distinguir entre una salida buena y mala, respaldando su juicio con evidencia, no solo impresiones.
  • Puedes reemplazarlo: conoces las dependencias del sistema, el coste de trasladarlo y quién más podría realizar el trabajo.

La mayoría de los traspasos solo proporcionan la primera capacidad y omiten las otras tres, lo que provoca que los sistemas se desvíen con el tiempo.

La documentación importante

La documentación se redacta para cumplir con una cláusula contractual, por lo que describe una arquitectura que nadie tocará jamás y deja de lado las cosas de las que realmente necesitan. Mantén la lista breve e insiste en estas:

  • Un manual para situaciones de fallo: los cinco problemas más probables, cómo se verían desde el exterior y los tres primeros pasos para cada uno. Escrito para la persona de turno, no para un ingeniero.
  • Un conjunto de evaluación: entre 100 y 200 casos reales con la respuesta correcta para cada uno, acordados por las personas que realizan el trabajo. Este es el activo más valioso del proyecto completo.
  • Un registro de cambios con motivos: no solo lo que se configuró, sino por qué existe una regla. Las reglas sin motivos serán eliminadas por el siguiente responsable.
  • Una hoja de dependencias y costes: todos los modelos, APIs y proveedores; su coste mensual; fechas de renovación del contrato; qué pasaría si desapareciera uno de ellos.
  • Un mapa de datos: dónde va cada dato, quién puede acceder a él y cuánto tiempo se conserva. Tus equipos legales y de seguridad necesitarán esta información sin previo aviso.

Todo lo demás es opcional. Si un documento no ayuda a alguien a operar, modificar, evaluar o reemplazar el sistema, es solo decoración.

Las tres personas que necesitas

No tienes que contratar a un equipo de aprendizaje automático. Necesitas tres individuos nombrados, y deberías nombrar a estos antes de que comience el proyecto, no durante el último mes.

  • Un propietario del negocio que decida qué debe hacer el sistema y gestione el presupuesto. Aprobó los cambios y rechaza la expansión del alcance. Este rol no es técnico.
  • Un custodio técnico capaz de leer la configuración, realizar un cambio controlado, probarlo y ponerlo en producción. Puede ser un desarrollador o ingeniero IT existente con capacidad asignada. No tienen que construir modelos; solo tienen que modificar e implementar los existentes.
  • Un propietario de calidad del departamento al que sirve el sistema - el gerente senior de reclamaciones, la enfermera jefa, el responsable de soporte-. Se encargan de mantener el conjunto de evaluación y decidir qué significa "bueno". Sin este rol, la calidad se convierte en cuestión de opinión en cuestión de semanas.

El coste total interno: suele ser una fracción de un puesto completo para cada uno, una vez que el sistema esté estable. El fallo no es el coste. Es que nadie fue nombrado.

Prueba el traspaso mientras aún puedas quejarte

No aceptes la documentación como prueba del traspaso. Realiza una prueba en vivo durante las últimas semanas del contrato, mientras los consultores aún estén bajo contrato.

Elige un cambio real - añadir un nuevo producto al conocimiento, ajustar una regla sobre lo que el sistema se niega a responder o sustituir una tabla de precios actualizada-. Pide a tu propio equipo que lo realice, con la presencia de los consultores pero en silencio. Tima el proceso. Luego, haz que tu propietario de calidad ejecute el conjunto de evaluación y confirme que no se ha roto nada más.

Si tu equipo completa esto en un día, eres dueño del sistema. Si tarda una semana y tres preguntas, has encontrado las brechas exactas para cerrarlas antes de que terminen las facturas. Cualquiera de los resultados es mucho más valioso que un formulario de traspaso firmado.

Incluye esto en el contrato desde el principio. Los hitos de traspaso, un equipo receptor nombrado y una prueba de cambio supervisada son todos más fáciles de negociar antes de comenzar el trabajo que después.

Así es como construimos en Hercules A, y significa que nuestros proyectos terminan. Y eso es el punto. La medida de un buen proyecto de IA no es cuán profundamente están integrados los consultores un año después - es cuánta confianza tienen tus propios empleados para cambiar el sistema sin llamar a nadie.

Artículos · Hercules A

Ideas para adaptar tu empresa a la IA.

Contáctanos