Inteligencia artificial en empresas: del piloto a la operación

La implementación de inteligencia artificial en empresas debería mejorar de forma medible un flujo de trabajo acotado dentro de un plazo de revisión de 90 días, con un responsable designado y una alternativa operativa. Hay que empezar por el trabajo que se quiere mejorar, asegurar los datos y los accesos, elegir cómo ponerlo en marcha y demostrar, mediante un piloto comparado con el proceso actual, que merece ampliarse. La fecha límite sirve para tomar una decisión; no autoriza a poner en producción un flujo que no supera las comprobaciones.

¿Qué implica implementar IA?

Implementar IA consiste en convertir un caso de uso aprobado en un proceso que las personas puedan operar, medir y mantener. Un modelo que funciona es solo una de las piezas. También hacen falta datos cuyo uso esté autorizado, integración con el flujo de trabajo existente, revisores capacitados, mecanismos para gestionar fallos y alguien que asuma la responsabilidad después del lanzamiento.

Un piloto se parece a un ensayo general. Una escena convincente demuestra poco si toda la función depende de que el director susurre cada frase. El flujo está listo para ampliarse cuando los usuarios habituales pueden completar el trabajo y resolver los problemas sin tener al lado a quien lo desarrolló.

La guía de implementación de Microsoft también incluye la preparación, las personas y la supervisión dentro de la implementación. La diferencia práctica está entre obtener una respuesta de la IA y conseguir, a través de todo el proceso, un resultado que el negocio acepte.

Si todavía no está definido el objetivo de negocio, conviene resolverlo con la guía de estrategia de IA. Una vez acordado, el siguiente entregable es la evidencia de que un flujo de trabajo concreto funciona.

Las guías citadas se consultaron el 28 de octubre de 2026. El calendario y las comprobaciones de aceptación que siguen son prácticas operativas propuestas. Las cifras del ejemplo son hipotéticas; no corresponden a una implementación real.

Inteligencia artificial en empresas: una hoja de ruta en siete pasos y 90 días

El calendario debe servir para tomar decisiones y sacar a la luz las dependencias. Solo hay que avanzar cuando la evidencia sea suficiente, aunque eso implique reducir el alcance del flujo o prolongar el piloto.

Esta secuencia propuesta parte de un flujo acotado que utiliza sistemas existentes y capacidades de IA disponibles. No supone un compromiso de resolver problemas importantes de datos, entrenar un modelo nuevo o aprobar un sistema con consecuencias de gran alcance dentro del mismo plazo. En cuanto se elija el flujo, hay que empezar a tramitar los accesos a los datos, las compras y las revisiones de especialistas.

Una persona puede desempeñar varios roles. Aun así, cada responsabilidad necesita un nombre, tiempo asignado y autoridad para ejercerla. Hay que designar desde el principio a quien se hará cargo de la operación; el último paso confirma que puede asumirla.

1. Elegir un flujo de trabajo con un final claro

Conviene elegir una tarea recurrente cuyas entradas, resultado aceptable y responsable de negocio se puedan identificar. El primer alcance debe ser lo bastante pequeño para poder revisarlo y lo bastante frecuente para generar evidencia útil durante el piloto.

Para quien dirige las operaciones de atención al cliente, «mejorar el servicio con IA» es demasiado amplio. Un alcance viable sería: redactar respuestas a preguntas habituales sobre el producto a partir de artículos de ayuda aprobados y entregar cada borrador a un agente para que lo revise. Quedan fuera las decisiones sobre reembolsos, los cambios en cuentas, los compromisos contractuales y el envío de respuestas.

Antes de cambiar el proceso actual, hay que seguir casos reales de principio a fin. Registrar qué inicia la tarea, qué información hace falta, qué acciones se realizan, cómo pasa el trabajo de una persona a otra y en qué momento se considera terminado. Si las solicitudes quedan detenidas por falta de información, redactar más rápido puede dejar intacta la principal causa de demora.

Preparar una ficha breve del flujo de trabajo que incluya:

• Inicio y final: qué activa la tarea y qué se considera un resultado aceptado.
• Casos elegibles: qué solicitudes entran en el piloto y cuáles siguen en el proceso existente.
• Facultades: qué puede leer, proponer y modificar la IA, y qué exige una decisión humana.
• Aceptación: cómo distingue el revisor entre un resultado aceptable, uno corregible y uno inaceptable.
• Responsabilidad: quién decide si el resultado mejoró y quién atiende las excepciones.

Para los borradores de atención al cliente, los criterios podrían exigir instrucciones correctas, una fuente aplicable, ninguna promesa sin respaldo y una derivación adecuada cuando la fuente no permita responder. Un tono impecable no compensa aplicar una política de cuentas equivocada.

Fallo que conviene vigilar: la tarea se amplía cada vez que alguien ve otra demostración atractiva. Un asistente de redacción termina recibiendo, casi sin advertirlo, permiso para resolver disputas o modificar registros.

Comprobación para detectarlo: pedir al responsable de negocio y a una persona que realiza el trabajo a diario que clasifiquen, por separado, un conjunto variado de casos recientes según estén dentro o fuera del alcance. Resolver las discrepancias antes de desarrollar. Si no pueden acordar qué debe gestionar el sistema, el alcance todavía no está listo.

Ejemplos de implementación de IA: el menor alcance que aporte valor

Quien funda una empresa de servicios podría empezar por un resumen interno de reuniones cuyas acciones acordadas se revisan antes de compartirlo. Una persona del área financiera podría extraer campos de facturas manteniendo aparte la autorización de pagos. Quien desarrolla por su cuenta podría clasificar las solicitudes entrantes en las colas existentes antes de intentar crear un agente que elija y ejecute sus siguientes acciones.

Son diseños posibles, no afirmaciones de que un producto concreto pueda ejecutarlos con fiabilidad. Conviene elegir el que ofrezca evidencia accesible, una vía reversible ante los fallos y un revisor capaz de explicar qué significa «correcto». Si un proceso basado en reglas ya resuelve la tarea de forma adecuada, hay que conservarlo.

2. Verificar los datos y los accesos antes de conectar el modelo

La información necesaria debe poder utilizarse y contar con autorización para este flujo de trabajo. No hace falta depurar todos los datos de la empresa para probar una tarea acotada, pero sí saber en qué fuentes puede confiar esa tarea.

En el ejemplo de atención al cliente, hay que identificar la colección de ayuda aprobada, quién responde por cada política y cómo se determina que un artículo está vigente u obsoleto. Una respuesta histórica no se convierte en una fuente autorizada por aparecer en una solicitud cerrada. Puede contener una excepción puntual, una política vencida o información privada de otra persona.

Preparar un registro de datos y accesos para las fuentes seleccionadas. Incluir la ubicación de la fuente, su responsable, la finalidad autorizada, los grupos de usuarios permitidos, los requisitos de actualización, las reglas de conservación y el método para retirar el acceso. Si la información se copia a un índice de búsqueda, una caché o registros, incluir también esos repositorios derivados.

Después, seguir una solicitud real a lo largo del recorrido propuesto. ¿Puede la aplicación recuperar el artículo aprobado pertinente? ¿Distingue la política vigente de una versión anterior? ¿Dispone el revisor de suficiente contexto de la fuente para comprobar el borrador? ¿Qué ocurre cuando falta la fuente o hay contradicciones?

La guía de implementación de IBM trata la calidad y la accesibilidad de los datos como un paso explícito de la implementación. Para concretarlo, hay que probar las identidades y los documentos que utilizará el flujo, sin dar por suficiente una demostración con una cuenta de administrador.

Implementación de IA generativa: los permisos deben aplicarse fuera del prompt

La IA generativa produce contenido, como un borrador de respuesta. Aportarle documentos relevantes le da material con el que trabajar; no elimina la necesidad de controlar qué documentos recibe.

Los permisos de la aplicación y del almacenamiento deben hacer cumplir las restricciones de acceso. Una instrucción que diga «no reveles información restringida» no sustituye a impedir que se recupere información sin autorización. El flujo de redacción debe disponer únicamente de las acciones que necesita, y la aplicación debe hacer cumplir la restricción de envío.

Fallo que conviene vigilar: la demostración funciona con una cuenta privilegiada, pero los usuarios habituales reciben respuestas incompletas o pueden recuperar información a la que nunca deberían acceder.

Comprobación para detectarlo: realizar pruebas con un usuario autorizado y otro al que se deba denegar el acceso. Utilizar un documento de prueba aprobado que deba permanecer inaccesible para este último y, después, probar la retirada del documento o la revocación del acceso a lo largo de todo el recorrido de recuperación. Comprobar también que los repositorios derivados y las sesiones existentes se comporten según lo previsto. Una única prueba superada aporta evidencia sobre ese caso; no demuestra una seguridad universal.

Si siguen sin resolverse la responsabilidad, el uso autorizado o la disponibilidad de datos utilizables, recurrir a la evaluación de preparación para la IA para asignar el trabajo pendiente. Hasta que los accesos estén listos, mantener el piloto sobre material de muestra autorizado.

3. Comparar comprar, configurar y desarrollar con las mismas pruebas

Hay que elegir la vía de implementación más sencilla que cumpla los requisitos de aceptación, acceso y operación del flujo. Antes de comprometerse con una opción, comparar las alternativas con los casos y las restricciones propios.

Un marco para decidir cómo implementar la IA

Comprar cuando un producto existente encaje con la tarea y sus controles superen las comprobaciones. En el flujo de atención al cliente, esto implica verificar la conexión real con las fuentes, la experiencia de revisión, los permisos, el registro de resultados y la alternativa ante fallos. La desventaja es depender del comportamiento del proveedor y de las opciones de configuración disponibles. Que una función aparezca en una presentación comercial no demuestra que encaje con el proceso.

Configurar cuando el producto de base sea adecuado, pero haya que adaptarlo al flujo aprobado. Puede ser necesario ajustar instrucciones, selección de fuentes, reglas de derivación y pasos de revisión. Esto permite evitar desarrollo a medida innecesario, pero la configuración también es lógica que debe mantenerse. Alguien debe gestionar sus versiones, probar los cambios y conservar las conexiones con las fuentes.

Desarrollar cuando siga sin cubrirse un requisito necesario y se pueda asumir la responsabilidad del sistema resultante. Una cadena de aprobación particular o una integración poco habitual pueden justificar el desarrollo a medida. Desarrollar el flujo no implica automáticamente entrenar un modelo. Puede consistir en programar los permisos, la recuperación de información, la revisión y los registros en torno a un servicio de modelos existente. A cambio, se asume la responsabilidad de los fallos de integración, las actualizaciones y el soporte.

La guía de ingeniería sobre agentes de Anthropic recomienda empezar por la solución eficaz más sencilla y añadir complejidad cuando esté justificada. Ese principio también sirve para la implementación: una secuencia predecible de redacción y revisión no necesita que un modelo invente su propio procedimiento operativo.

Las soluciones preseleccionadas deben recibir los mismos casos de muestra autorizados, los mismos criterios de evaluación de resultados y los mismos controles exigidos. Incluir entradas difíciles, fuentes no disponibles, permisos de usuarios habituales y un fallo del servicio. Preguntar cómo se exportarían los registros pertinentes y cómo continuaría el trabajo si terminara la relación con el proveedor.

Si se contrata a un socio de implementación, convertir esas comprobaciones en entregables contractuales, junto con la documentación y el traspaso. Un socio puede aportar capacidad de ejecución; la empresa sigue necesitando a alguien que acepte el resultado y se haga cargo del proceso a largo plazo.

Fallo que conviene vigilar: gana una demostración impecable y, después de asumir el compromiso, aparecen requisitos de integración o acceso que no se habían cubierto.

Comprobación para detectarlo: exigir una demostración mínima de principio a fin, desde una solicitud autorizada hasta un resultado revisado y un fallo del que se pueda recuperar, aplicando los mismos criterios a todas las alternativas. Dejar constancia explícita de los requisitos pendientes. Una solución con una carencia crítica no aprueba porque su texto generado suene mejor.

4. Ejecutar un piloto comparado con una línea de base

El piloto debe responder si el flujo propuesto mejora el trabajo en unas condiciones definidas. Para ello necesita un proceso de comparación, casos representativos y criterios de aceptación acordados antes de conocer los resultados.

Hay que empezar pronto a registrar el proceso existente, mientras se resuelven los datos y las opciones de implementación. La línea de base es el proceso actual medido con las mismas definiciones que se utilizarán en el piloto. La guía de medición de Google Cloud recomienda establecer esa referencia y diseñar la medición antes del lanzamiento.

Para la redacción de respuestas de atención al cliente, registrar el tiempo de trabajo activo hasta obtener una respuesta aceptada, el tiempo total transcurrido hasta completarla, la calidad según los criterios definidos y los motivos de derivación. El trabajo activo incluye leer, comprobar, editar y corregir errores. El tiempo transcurrido también incluye las esperas, de modo que un modelo más rápido puede coexistir con una respuesta más lenta al cliente.

Elegir un método de comparación adecuado para el trabajo. Cuando sea viable, asignar aleatoriamente casos elegibles comparables al proceso actual o al proceso asistido por IA. Si unos casos influyen en otros, como sucede dentro de una misma conversación con un cliente, mantener juntos los casos relacionados. Si hay que comparar el antes y el después, documentar los cambios de personal, carga de trabajo y composición de las solicitudes: limitan la confianza con la que se puede atribuir el resultado a la IA.

Mantener separados los ejemplos utilizados para ajustar el flujo y los casos con los que se evaluará. Un conjunto reservado para evaluación contiene casos que no se exponen repetidamente durante los ajustes. Incluir solicitudes normales y casos difíciles: información incompleta, fuentes contradictorias, lenguaje poco habitual y una pregunta que el material aprobado no permita responder.

Avanzar por el piloto siguiendo una secuencia controlada:

1. 1

   Reproducir casos históricos autorizados

   Ejecutar la solución candidata sobre casos anteriores sin realizar acciones reales. Pedir a un revisor que conozca el tema que aplique los criterios de evaluación. Comprobar si la evidencia recuperada era aplicable, si el borrador la utilizó correctamente y si el sistema rechazó o derivó de forma adecuada las solicitudes sin respaldo.

2. 2

   Observar entradas reales sin modificar los resultados

   En modo sombra, la solución candidata procesa trabajo real autorizado mientras el proceso existente sigue siendo responsable del resultado. Buscar entradas incompletas, latencia, dependencias no disponibles y tipos de casos inesperados. El modo sombra también exige la autorización adecuada para utilizar los datos.

3. 3

   Introducir la asistencia en un grupo acotado

   Permitir que operadores capacitados utilicen la solución candidata dentro del alcance acordado. Mantener la aprobación humana para las respuestas a clientes. Registrar los intentos de uso, los casos en que no se utilizó, los fallos, las revisiones, las correcciones y el resultado final, con suficiente información sobre la configuración y la versión de las fuentes para investigar un resultado.

Antes del uso asistido, acordar las reglas de decisión: calidad exigida, esfuerzo aceptable, demoras máximas toleradas y fallos que obligan a pausar el flujo de inmediato. En este ejemplo limitado a borradores, una divulgación no autorizada o un envío sin aprobación deberían provocar una pausa y una investigación. Un fallo grave no debe quedar oculto en una puntuación media.

Fallo que conviene vigilar: los usuarios más entusiastas eligen los casos fáciles, quien desarrolló el sistema corrige los errores sin dejar constancia y el informe solo incluye los borradores satisfactorios.

Comprobación para detectarlo: cotejar cada caso elegible con el registro del piloto, incluidos aquellos en los que no se utilizó la IA o esta falló. Contabilizar la ayuda de quien desarrolló el sistema como trabajo. Pedir a otra persona que revise el proceso de evaluación y una muestra de las decisiones.

No existe un tamaño de muestra ni un objetivo de exactitud universal que haga seguro cualquier flujo de IA. La evidencia necesaria depende de la variedad de los casos, la gravedad de los errores y la precisión que requiera la decisión. Si un flujo de poco volumen no genera evidencia suficiente dentro del periodo de revisión, prolongar el piloto o mantener un control humano más estricto.

5. Medir el flujo completo y tomar una decisión

La mejora debe evaluarse sobre todo el trabajo elegible, incluidos los casos sin uso de IA, la revisión y el recurso al proceso alternativo. Que una tarea asistida sea más rápida puede traducirse en una mejora mucho menor del proceso completo del que se es responsable.

Veamos este cálculo hipotético, con una composición de casos comparable y los mismos criterios de calidad. Supongamos que todos los casos terminan siendo aceptados después de las correcciones necesarias; los tiempos incluyen ese trabajo. Los recuentos de calidad corresponden a la primera revisión. Son supuestos didácticos, no una referencia de rendimiento ni resultados publicados de un cliente.

En este ejemplo, el subconjunto asistido requiere un 25% menos de tiempo de trabajo activo: pasar de 12 a 9 minutos ahorra 3 minutos por caso asistido. Sin embargo, el flujo completo requiere un 15% menos de tiempo de trabajo activo, porque los demás casos siguen necesitando el proceso manual.

El cálculo es: 60 × 9 + 40 × 12 = 1,020 minutos. Frente a los 1,200 minutos de la línea de base, se liberan 180 minutos, o 3 horas, en los 100 casos elegibles. Esto no demuestra un ahorro de dinero, y la pequeña diferencia en los recuentos de calidad tampoco prueba que la calidad haya mejorado.

Mantener un registro para la toma de decisiones que reúna las medidas de resultado, esfuerzo, adopción y fallos. En este ejemplo, la asistencia llegó al 60% de los casos elegibles. Antes de interpretar esa cifra como resistencia de los usuarios, investigar los casos restantes: la falta de fuentes, las solicitudes inadecuadas o una experiencia de revisión más lenta pueden explicar que no se utilizara la herramienta.

Revisar los resultados por tipos de casos relevantes y grupos de operadores, además del resultado global. Una buena media puede ocultar un rendimiento deficiente en una categoría importante de solicitudes. Comprobar también los casos abiertos o demorados; medir únicamente el trabajo completado puede ocultar una acumulación creciente de pendientes.

El AI Risk Management Framework Playbook del National Institute of Standards and Technology recomienda comparar el comportamiento en producción con la evidencia previa al despliegue y asignar responsabilidades claras a los revisores humanos. Las definiciones deben mantenerse estables cuando el flujo pase al uso cotidiano.

Fallo que conviene vigilar: el informe cuenta los resultados generados, extrapola a partir del subconjunto que funcionó bien o convierte directamente el ahorro de tiempo estimado en un retorno financiero.

Comprobación para detectarlo: recalcular el resultado con todos los casos elegibles y todo el trabajo necesario; después, examinar por separado la calidad y los fallos graves. Recurrir a la guía de ROI de la IA cuando llegue el momento de evaluar cómo cambia el gasto o la producción del negocio gracias a la capacidad liberada.

Hay que tomar una decisión: ampliar el alcance probado, corregir un defecto concreto y volver a probar, prolongar la medición para resolver la incertidumbre o detener el trabajo. Cada decisión necesita un motivo y un responsable. «Seguir experimentando» sin una pregunta que resolver no es un resultado útil del piloto.

6. Ampliar el despliegue en etapas reversibles

Ampliar solo una dimensión importante a la vez permite entender qué ha cambiado. Más usuarios, casos diferentes, otra unidad de negocio y mayores facultades para actuar son cambios distintos, cada uno con sus propias necesidades de evidencia.

Para la redacción de respuestas de atención al cliente, incorporar al siguiente grupo con los mismos tipos de solicitudes aprobados y las mismas reglas de revisión. No añadir simultáneamente nuevos idiomas, nuevas colecciones de fuentes y el envío automático. Un piloto exitoso en un entorno acotado no valida esas ampliaciones.

Capacitar a los operadores para los fallos del flujo, además de para los casos en que todo funciona. Cada persona debería poder identificar una afirmación sin respaldo, comprobar la evidencia, rechazar un borrador y derivar la solicitud manualmente. Los controles deben estar donde se realiza el trabajo; una diapositiva de capacitación aparte no puede impedir que una aplicación envíe una respuesta.

Antes de ampliar, ensayar una interrupción del servicio o dejar una fuente deliberadamente fuera de servicio. Confirmar que las solicitudes lleguen a la cola manual con suficiente contexto para continuar, que siga siendo visible quién es responsable y que no se actúe dos veces por error sobre la misma solicitud. En los flujos con efectos externos, definir cómo detectar y corregir las acciones ya ejecutadas. Desactivar un modelo no revierte un correo enviado ni una actualización de la base de datos.

Supervisar las mismas medidas de resultado y esfuerzo utilizadas durante el piloto, además de las señales operativas que explican los fallos: disponibilidad de dependencias, tiempos de espera, vigencia de las fuentes, intervenciones que anulan decisiones del sistema e informes de incidentes. Asignar un destinatario y una respuesta esperada a cada alerta que requiera actuar.

Fallo que conviene vigilar: el éxito del piloto dependía de revisores expertos o del apoyo constante de quien desarrolló el sistema, y el siguiente grupo no logra reproducirlo.

Comprobación para detectarlo: pedir a un operador ajeno al piloto original que complete un caso difícil y el ejercicio de recuperación con la capacitación y el manual operativo. Observar sin orientarlo. Corregir las carencias de instrucciones, controles o capacidad antes de incorporar más usuarios.

La decisión de ampliar el despliegue debe indicar el alcance añadido, la evidencia revisada, quién lo autoriza y las condiciones para pausar y reanudar. Mantener disponible el proceso anterior hasta haber demostrado que la alternativa puede absorber la carga de trabajo que quizá deba asumir.

7. Transferir el flujo a quien se hará cargo de operarlo

El responsable de operación debe poder mantener la utilidad del flujo una vez terminado el proyecto de implementación. Para ello necesita autoridad, capacidad de soporte y un proceso de cambios; no basta con un correo que anuncie el cierre del proyecto.

La responsabilidad de negocio debe seguir en manos de quien responde por el resultado. En el ejemplo de atención al cliente, la persona que dirige el área acepta la calidad de las respuestas y el desempeño del servicio. Un responsable de mantenimiento técnico atiende los fallos de integración y configuración; los responsables de las fuentes mantienen el conocimiento aprobado. Hay que designar contactos suplentes y decidir quién responde cuando el responsable habitual no está disponible.

La documentación del traspaso debe incluir:

• El alcance aprobado del flujo, los grupos de usuarios y los permisos para actuar.
• La línea de base, los casos de evaluación, los criterios, los últimos resultados y las limitaciones conocidas.
• Las ubicaciones de las fuentes, sus responsables, las expectativas de actualización y los procedimientos para retirar el acceso.
• Registros de configuración y dependencias suficientes para investigar un cambio.
• La supervisión, los contactos para incidentes, la autoridad para pausar y reanudar, y las instrucciones de recuperación.
• La capacitación, el tiempo asignado a soporte y la siguiente revisión operativa.

Las directrices MANAGE de NIST abarcan la autoridad para omitir o desactivar un sistema, junto con la supervisión, la recuperación de incidentes y la gestión de cambios. Esas responsabilidades deben asignarse a personas concretas para este flujo de trabajo.

Tratar las actualizaciones del modelo, las instrucciones revisadas, los cambios en las colecciones de fuentes y las nuevas integraciones como cambios que pueden afectar al resultado. Ejecutar la evaluación pertinente antes de ampliar el uso de una configuración modificada y observar después su comportamiento en producción. Si un proveedor controla una actualización que no se puede aplazar, definir cómo detectarla, evaluar sus efectos y suspender el flujo afectado si hace falta.

La implementación de IA continúa después del lanzamiento

Realizar una revisión operativa a partir de los resultados reales y los incidentes pendientes. Añadir al conjunto de evaluación los nuevos casos de fallo descubiertos. Retirar las fuentes obsoletas. Reducir o retirar el flujo si desaparece su beneficio o si mantenerlo supera la capacidad asignada.

Cuando un centro de excelencia en IA proporcione acceso compartido, evaluación o soporte técnico, dejar constancia del servicio que presta y de la vía para escalar problemas. Esa función compartida no elimina la responsabilidad del encargado local sobre el proceso de negocio.

Fallo que conviene vigilar: el proyecto se cierra y todos dan por hecho que otra persona se encargará del deterioro, los cambios en las fuentes y las solicitudes de soporte.

Comprobación para detectarlo: pedir al responsable que recibe el flujo que gestione un incidente simulado y un cambio propuesto con la documentación del traspaso, sin que quien lo desarrolló dirija la respuesta. Registrar la aceptación solo cuando ese responsable tenga el acceso, la autoridad y la capacidad para hacer el trabajo el día 91.

¿Qué expectativas son exageradas y quién debería actuar ahora?

La autonomía no es la meta por defecto. Un flujo supervisado que produzca trabajo útil de forma fiable puede ser el diseño permanente adecuado. Solo debe recibir mayores facultades cuando se hayan evaluado las nuevas consecuencias.

Un producto listo para usar tampoco equivale a una implementación terminada. La elección de las fuentes, las acciones permitidas, la capacitación de los usuarios y el resultado de negocio siguen siendo responsabilidad propia. Y volver a entrenar un modelo no es la solución automática a unos resultados decepcionantes: antes de elegir una medida correctiva, hay que investigar si el fallo procede de la falta de evidencia, una recuperación incorrecta, las instrucciones, la integración o el traspaso a una persona.

Quienes gestionan la operación deberían actuar ahora si cuentan con un resultado acordado, una tarea acotada, datos autorizados y tiempo para revisar los resultados. Su siguiente entregable es la ficha del flujo y la línea de base, seguido de la evidencia necesaria para cada decisión de puesta en producción.

Los fundadores que cuentan con financiación deberían proteger el alcance. Hay que exigir una mejora operativa demostrable antes de incorporar otras áreas. También deben asignar recursos para el tiempo de revisión y soporte, además del desarrollo.

Los directores de tecnología y los desarrolladores deberían posponer una mayor autonomía si aún no están resueltos los permisos, la observabilidad o la recuperación. Para quien desarrolla por su cuenta, una capacidad de mantenimiento limitada es por sí sola un motivo para preferir un sistema más sencillo.

Quienes compran deberían vincular los compromisos a la evidencia de aceptación. Confirmar quién aporta las integraciones, las pruebas, la documentación y el soporte continuo. Una demostración atractiva no resuelve esas responsabilidades.

Un departamento cuyo proceso actual ya satisface sus necesidades puede conservarlo. Que otra parte de la empresa tenga una iniciativa de IA no justifica sustituir un flujo que funciona bien.

Por dónde empezar el lunes

Reunir al responsable del flujo, a una persona que realiza el trabajo a diario y al responsable de mantenimiento técnico para revisar casos recientes. Escribir el alcance de la tarea y los criterios de aceptación. Designar al responsable de las fuentes, programar la prueba de acceso permitido y denegado, y empezar a medir el proceso actual.

Anotar en la misma ficha la fecha de decisión del piloto y el nombre de quien se prevé que asuma la operación. En esa revisión, la pregunta será si la evidencia justifica dar el siguiente paso y, si no es así, qué trabajo concreto queda pendiente.

Para recibir guías prácticas sobre cómo incorporar la IA al trabajo diario, suscríbete al boletín.