Requisitos para un consultor

Qué cubren realmente los requisitos para un consultor

Cuando un equipo de negocio empieza a evaluar un proyecto de IA o automatización, 'requisitos para un consultor' suele significar dos cosas distintas a la vez: qué necesita el consultor de ti para hacer bien su trabajo, y qué deberías exigirle antes de dejarlo acercarse a tus sistemas y datos. Ambas importan, y confundirlas es una fuente habitual de decepción.

Este artículo se centra sobre todo en el segundo sentido, porque es ahí donde los directivos tienen más margen de acción y menos experiencia. Un consultor incapaz de expresar con claridad sus propios requisitos, o que acepta un encargo vago sin cuestionarlo, ya es en sí mismo una señal a tener en cuenta.

Empieza con un objetivo de negocio explícito, no con una lista de deseos tecnológicos

Un fallo frecuente es encargar un proyecto definido por una herramienta ('queremos un chatbot', 'queremos automatizar correos') en lugar de por un resultado que el negocio realmente necesita. Un consultor que merezca la pena cuestionará los encargos vagos y preguntará qué cambio medible debe producir el proyecto, para quién y para cuándo.

Esto no es un formalismo. Sin un objetivo explícito, no hay forma de juzgar después si el proyecto tuvo éxito, y el alcance tiende a desviarse a medida que cada parte interesada proyecta sus propias expectativas sobre una iniciativa mal definida. Exigir al consultor que escriba el objetivo, en términos de negocio claros, antes de iniciar cualquier diseño técnico, es una comprobación razonable y de bajo costo.

• Pide el objetivo en una sola frase, en términos de negocio, no técnicos
• Pregunta qué contaría como un resultado fallido, no solo como un éxito
• Verifica que el objetivo lo posea alguien con autoridad para cambiar la forma de trabajar, no solo un patrocinador de TI

Requisitos de acceso y control de datos

Todo proyecto de IA o automatización involucra datos, y la calidad y los límites de esos datos determinan en gran medida lo que es alcanzable. Un consultor serio preguntará desde el principio qué datos existen, dónde están, quién es su propietario y qué restricciones se aplican, en lugar de asumir que se le concederá acceso sin más una vez iniciado el proyecto.

Los directivos también deben exigir la disciplina inversa: una descripción por escrito de qué datos necesita el consultor, por qué, durante cuánto tiempo y bajo qué controles de acceso. Las peticiones vagas de 'acceso total' a los sistemas deberían generar preguntas. Un acceso controlado y limitado al objetivo específico es un requisito base razonable, y el consultor debería poder justificar cualquier excepción a él.

Los problemas de calidad de datos descubiertos a mitad del proyecto son mucho más costosos de corregir que los detectados durante la definición del alcance. Preguntar al consultor cómo piensa evaluar la calidad de los datos antes de comprometerse con un plazo de entrega es un requisito justo y útil.

Revisión humana y salvaguardas adecuadas

Como los resultados de un proyecto de IA o automatización dependen en gran medida del contexto y de la calidad de lo que lo alimenta, ningún consultor responsable debería presentar un sistema como algo que se despliega y luego se ignora. Un requisito que vale la pena exigir es un paso definido de revisión humana para cualquier salida que afecte a clientes, dinero, cumplimiento normativo o seguridad, al menos hasta que el comportamiento del sistema se entienda bien en producción.

Las salvaguardas deben ser proporcionales al riesgo y no uniformes. Una automatización interna de bajo riesgo puede necesitar una revisión más ligera que un proceso orientado al cliente. Pide al consultor que proponga dónde se sitúa la revisión humana en el flujo de trabajo y por qué, en lugar de aceptar una garantía genérica de que 'el sistema es seguro'.

Aquí también la gobernanza se cruza con la practicidad: unas salvaguardas que hacen el sistema inutilizable anulan su propósito, así que el requisito correcto es un proceso de revisión ajustado al riesgo real, no uno máximo aplicado a todo.

Medición después del despliegue, no solo en la entrega

Un proyecto que solo se mide en el momento de la entrega, con una demo o un conjunto de datos de prueba, dice poco sobre cómo se comportará una vez que intervengan usuarios y datos reales. Un requisito razonable es que el consultor defina de antemano qué se medirá en producción y durante qué período, y que siga involucrado, o entregue un método claro, para revisar esos datos después.

Esto conecta con el objetivo explícito del principio: si el objetivo se formuló como un resultado medible, la medición en producción es simplemente la forma de comprobar si se alcanzó. Los consultores que evitan comprometerse con una medición posterior al despliegue, o que tratan la entrega como la línea de meta, merecen más preguntas.

Cómo aborda Victor Laybats estos requisitos

Victor Laybats ofrece servicios de ingeniería de IA y automatización desde París y documenta un enfoque pensado para ir desde la definición inicial del alcance hasta el despliegue y el seguimiento, sin detenerse en la entrega. Esa estructura se describe públicamente para que los futuros clientes puedan ver, antes de contratar, aproximadamente cómo se definiría y revisaría un proyecto.

Vale la pena ser precisos sobre lo que esto significa y lo que no: describe un enfoque y un conjunto de principios declarados, no una garantía de resultados. Como con cualquier consultor, los resultados dependen del contexto del cliente, de sus sistemas existentes y de la calidad de los datos implicados, y no se afirma nada más allá de eso aquí.

Un breve ejemplo ilustrativo (solo a título de ejemplo)

Consideremos un minorista mediano hipotético que quiere automatizar parte de su bandeja de soporte al cliente. Antes de aceptar nada, el equipo de negocio podría exigir al consultor que declare el objetivo (por ejemplo, reducir el tiempo medio de respuesta en una categoría definida de tickets), especifique exactamente a qué datos y sistemas necesita acceder y durante cuánto tiempo, describa dónde un humano revisará o anulará las respuestas automatizadas, y se comprometa a un período de medición tras el lanzamiento con métricas acordadas.

Este ejemplo es ilustrativo, no una afirmación sobre un encargo o resultado real. Su propósito es simplemente mostrar cómo los cuatro principios anteriores se traducen en preguntas concretas que un equipo de negocio puede plantear en una primera reunión, en lugar de supuestos que aceptar por fe.