Consultoría y servicios de IA

Qué deberían significar la consultoría y los servicios de IA para su organización

Para un equipo directivo, la consultoría y los servicios de IA solo son útiles cuando convierten una intención de negocio en un flujo de trabajo que alguien pueda ejecutar, probar y detener. La etiqueta abarca ofertas muy distintas, desde talleres de estrategia hasta la integración de modelos o la operación continua. Antes de comparar proveedores, decida cuál de ellas está contratando y cómo es un primer paso terminado.

Esta orientación procede de Victor Laybats, un ingeniero con base en París que trabaja en proyectos de IA y automatización desde la definición inicial del alcance hasta el despliegue y el seguimiento. Refleja un método documentado, no un estudio del mercado ni un registro de resultados de clientes. Tómela como una forma de hacer mejores preguntas, no como prueba de que un enfoque concreto vaya a dar frutos en su contexto.

Empiece por un proceso con un responsable claro, no por una herramienta

El error más común es empezar con "necesitamos IA" o con una plataforma preferida. Un punto de partida más sólido es un único proceso descrito en términos sencillos: qué lo desencadena, qué resultado de negocio debe producir, quién es su responsable y qué sistemas toca. Si nadie puede nombrar al responsable, el proyecto no está listo para implementarse, sea cual sea la tecnología.

Un objetivo de negocio explícito también le da permiso para detenerse. Un buen primer encargo puede concluir que parte de un proceso debe seguir siendo manual porque el volumen es bajo, el criterio humano pesa mucho, la responsabilidad no está clara o las interfaces no están soportadas. Esa conclusión es un entregable legítimo. Protege a la organización de una demostración impresionante que después nadie puede operar con seguridad.

Qué debe entregar una fase de descubrimiento antes de escribir código

Pida un resultado de descubrimiento acotado antes de aprobar un desarrollo. Hace comparables las propuestas, porque cada proveedor debe describir el mismo proceso en los mismos términos concretos. También debe separar lo observado en su entorno de las suposiciones y las opciones futuras, para que sepa qué partes del plan siguen siendo conjeturas.

Las dependencias merecen especial atención. Algunas decisiones requieren acceso personal, la aprobación de un proveedor de software o una autorización interna de negocio. Deben aparecer como elementos visibles con responsables, no incluirse en silencio en una estimación de entrega. Una lista de comprobación práctica para el resultado del descubrimiento:

• Un mapa del flujo de trabajo con cada paso y cada traspaso
• Un inventario verificado de las integraciones implicadas
• Una clasificación de los datos que el proceso lee y escribe
• Las acciones que la automatización puede realizar y las que no
• Los puntos de revisión humana y quién se encarga de ellos
• Los casos de fallo conocidos y un responsable de la recuperación con nombre
• Los objetivos excluidos de forma explícita y un plan de medición

Datos controlados, salvaguardas y revisión humana

Un proyecto de IA útil se basa en datos cuyo origen, sensibilidad y reglas de acceso se conocen. Si no puede decir qué registros puede leer el sistema, dónde se almacenan sus resultados y quién puede cambiar sus permisos, las salvaguardas aún no están definidas. La calidad también importa: los resultados dependen en gran medida de las entradas, y un modelo no puede compensar datos de origen incompletos o incoherentes.

La revisión humana no es señal de una automatización débil; es la forma de que las decisiones que siguen siendo humanas permanezcan visibles. Sitúe la revisión donde un error sería costoso o difícil de revertir, por ejemplo antes de que un mensaje llegue a un cliente o antes de modificar un registro en un sistema de referencia. El diseño debe dejar claro cuándo el sistema tiene dudas y cómo toma el relevo una persona.

Medir en producción y los límites que se aplican

Un prototipo o una arquitectura de referencia pueden explicar un método, pero no demuestran el retorno de la inversión, el tiempo ahorrado ni un resultado para un cliente. Acuerde antes del lanzamiento qué se medirá cuando el flujo de trabajo funcione con tráfico real: tasas de error, proporción de casos enviados a revisión, tiempo de gestión o cualquier indicador vinculado al objetivo declarado. Sin una línea base tomada antes del cambio, cualquier mejora que se afirme después será difícil de comprobar.

Desconfíe de cualquier proveedor que prometa ganancias fijas. Los resultados dependen de sus sistemas existentes, de sus procesos y de la calidad de lo que entra. Del mismo modo, estar vinculado a un estudio o figurar en un portafolio no implica un respaldo ni un resultado garantizado; las capacidades actuales deben comprobarse directamente. Las cuestiones legales o regulatorias sobre sus datos deben consultarse con asesores cualificados.

Ejemplo: definir el alcance de una solicitud hipotética de clasificación de facturas

Ejemplo hipotético, no un caso de cliente: un equipo de finanzas pide "IA para gestionar las facturas de proveedores". El descubrimiento lo reduce a un solo proceso: las facturas que llegan por correo electrónico se clasifican y se cotejan con los pedidos de compra, con el responsable de cuentas por pagar como propietario. El mapa muestra que tanto el buzón de correo como la herramienta contable tienen interfaces utilizables, pero las reglas de aprobación están en una hoja de cálculo que nadie mantiene.

El alcance resultante automatiza solo la extracción y el cotejo. Cualquier factura por encima de un umbral acordado, o cualquier discrepancia, pasa a una persona; la aprobación de pagos sigue siendo manual y se declara fuera de los objetivos. El plan de medición compara la precisión del cotejo y el volumen de revisión con unas semanas de línea base manual. Si la hoja de cálculo no puede ordenarse, la recomendación es resolver primero la responsabilidad y volver a plantear la automatización más adelante.