Elija una tarea, no un departamento entero
Comience por una actividad con entrada, resultado y responsable de corrección conocidos. Puede ser redactar una respuesta a una consulta interna, clasificar documentos o preparar pruebas para quien aprueba. Mida el tiempo actual, la frecuencia y el coste de un error. Un piloto útil se puede comparar con el procedimiento de hoy. El objetivo general de introducir IA en toda la empresa no ofrece un criterio para saber si el trabajo de alguien realmente mejoró.
Diferencie borrador, recomendación y acción ejecutada. Redactar un mensaje tiene riesgos distintos de cambiar un registro CRM o aprobar un pago. En el primer piloto deje las escrituras decisivas a una persona y mida si las propuestas ayudan. El marco AI RMF de NIST describe las funciones continuas gobernar, mapear, medir y gestionar. En un piloto pequeño significa nombrar un responsable, entender el impacto, medir fallos y decidir periódicamente si hay que cambiar el proceso.
Datos y permisos marcan la frontera
Identifique los documentos y registros que necesita el asistente. Cada fuente tiene dueño, clasificación, periodo de validez y normas de acceso. El acceso de un empleado a un archivo no autoriza a entregar todo el repositorio empresarial al modelo. En búsqueda o RAG aplique permisos antes de enviar resultados al modelo. Conserve vínculo y versión de la fuente que sostiene cada respuesta, para que un revisor compruebe después de dónde salió la información.
Trate texto del usuario y páginas recuperadas como entrada no fiable. OWASP explica la inyección de instrucciones como un intento de cambiar el comportamiento del modelo mediante órdenes dentro del contenido. Un documento es dato, no autoridad para modificar permisos del flujo. Los instrumentos accesibles al modelo deben tener el alcance mínimo útil. Separe lectura y escritura, exija control adicional para acciones sensibles y nunca ponga claves secretas en el prompt. Las instrucciones del modelo no sustituyen el control de acceso.
La aprobación es un estado del proceso
Defina qué acciones ocurren automáticamente y cuáles esperan a una persona. Base el límite en el impacto: quién recibe el resultado, si cambia datos persistentes y si se puede deshacer. La guía de Microsoft distingue la aprobación obligatoria de la información que devuelve un borrador para corregirlo. Guarde el estado de la tarea pendiente para continuar horas después con las mismas pruebas, sin repetir todo y arriesgar una segunda acción.
Quien aprueba necesita ver entrada original, salida propuesta, fuentes y señales de incertidumbre. Un clic no debería autorizar cientos de cambios ocultos. El rechazo debe registrar un motivo apropiadamente breve y devolver el caso a un estado seguro. Compruebe el permiso del aprobador en el momento de actuar, no solo al crear la solicitud. Si no está disponible, la tarea espera o escala según una regla expresa; nunca debe adquirir permiso automáticamente.
La auditoría explica una operación concreta
Conserve identificador del caso, versión de instrucciones, modelo, fuentes, pasos propuestos, aprobación y cambios reales de cada ejecución. El registro debe servir para explicar incidentes sin copiar innecesariamente datos personales completos o documentos secretos. La retención depende del contexto legal y operativo de la empresa. Si el flujo llama a varios sistemas, use un identificador de correlación común en los registros. Sin él será difícil saber cuándo una sugerencia se convirtió en acción.
La respuesta del modelo puede ser correcta y fallar el conector que actúa después. Registre por separado decisión de IA, confirmación humana y resultado de la herramienta. Tras un timeout quizá no sepa si el sistema destino escribió el dato; repetir requiere identificador idempotente o comprobación segura del estado. La auditoría no es solo un historial de textos generados. Debe unir propuesta y consecuencia real e indicar quién respondió por cada transición.
Mida la calidad con excepciones reales
Antes del piloto prepare casos de trabajo habitual: entradas fáciles, incompletas, antiguas, sensibles y deliberadamente confusas. Para cada una defina el procedimiento esperado, no una sola frase ideal. Mida exactitud del borrador, correcciones humanas, tiempo de finalización y tipos de fallo. En búsqueda separe el error de encontrar la fuente correcta del error de redactar la respuesta. Si mejora la velocidad media pero empeoran excepciones críticas, el piloto no tuvo éxito.
Repita la evaluación al cambiar modelo, instrucciones, fuentes o permisos. Las personas suelen usar la herramienta de formas no previstas; observe nuevas situaciones y comentarios, no solo disponibilidad técnica. Registre coste de procesamiento, tiempo del aprobador y mantenimiento. Ahorrar segundos en un paso quizá no compense la revisión. La métrica operativa debe cubrir el proceso completo, desde entrada hasta decisión final, incluidos los casos que el modelo no puede resolver.
Alternativa y adopción
Si el modelo o una fuente no está disponible, el trabajo necesita una alternativa clara: procedimiento manual, búsqueda sin generación o tarea en pausa. Explique al usuario qué ocurrió y si se ejecutó alguna acción; una falsa impresión de finalización es peor que reconocer una caída. Desactivar la parte de IA no debe impedir acceder a los datos originales. Decida antes quién puede parar el flujo y cómo se investigan casos pendientes. Al recuperar el servicio evite que una acción en espera se ejecute dos veces.
Las personas deben saber cuándo ayuda la herramienta y cuándo conservan la responsabilidad. Una formación breve con ejemplos concretos es más útil que una lista general de capacidades. Reúna fallos reproducibles y ajuste entradas o procedimiento. Esta página no afirma ahorros de tiempo medidos para clientes de EXCOIN ni garantiza ausencia de errores. Primeros resultados útiles son mapa de tarea, fuentes y acciones permitidas, casos de evaluación y plan de aprobación humana. Muestran si conviene IA, reglas sencillas o cambiar el proceso.
Cierre el piloto decidiendo expresamente qué continúa y qué se elimina. Asigne quién mantiene fuentes, quién revisa propuestas incorrectas y cómo un cambio de modelo exige nuevas pruebas. Si nadie asume esas obligaciones, una demostración técnicamente correcta no debe considerarse un producto interno listo para el trabajo diario.