IA y automatización
Cómo probar una automatización con IA antes de usarla en tu empresa
Una guía para preparar un piloto de automatización con IA: casos de prueba, revisión humana, gestión de fallos y criterios para decidir si merece avanzar.
Una demostración puede clasificar una consulta correctamente y redactar una respuesta convincente. Antes de conectar esa automatización al trabajo diario, necesitas saber qué hará cuando falte información, llegue una petición extraña o falle una herramienta. Un piloto sirve para comprobarlo con un alcance pequeño y una forma clara de evaluar el resultado. Esta guía propone un ejemplo ilustrativo: organizar solicitudes de presupuesto y preparar borradores para que una persona los revise. Puedes adaptar el método a otros procesos de tu empresa.
1. Define una tarea y el límite de la prueba
Escribe qué entra, qué debe salir y qué acciones quedan permitidas. En nuestro ejemplo entra una consulta, sale una propuesta de categoría y se prepara un borrador de respuesta. Durante el piloto, el sistema no envía mensajes, no fija precios y no modifica oportunidades comerciales existentes.
Describe también el trabajo actual. ¿Quién lee la consulta? ¿Dónde la registra? ¿Qué información busca para contestar? Ese recorrido será tu referencia. Si todavía no hay un criterio compartido para clasificar solicitudes, acordadlo antes: el equipo necesita poder decidir qué respuesta considera correcta.
Elige un responsable del piloto y una persona que conozca la tarea. Acordad cuándo revisaréis los casos y qué condición obligaría a detener la prueba. Puede ser, por ejemplo, que el sistema asocie una consulta a la empresa equivocada.
2. Prepara datos que puedas utilizar
Para la primera prueba, redacta consultas ficticias que representen situaciones habituales. Evita copiar correos completos por comodidad. Incluye únicamente la información necesaria para comprobar la clasificación y el borrador; los nombres, direcciones y documentos internos pueden sustituirse por ejemplos preparados para ese fin.
Si después necesitas usar información real, revisa primero qué datos recibirá cada herramienta, quién tendrá acceso y qué condiciones ofrece el proveedor para su tratamiento y conservación. Define también dónde guardarás los resultados del piloto y cuándo dejarán de ser necesarios.
Prepara una versión revisada de los servicios, condiciones y respuestas que el sistema puede consultar. Si una pregunta depende de una tarifa que no has facilitado, el comportamiento esperado debe ser pedir revisión. No le pidas que complete por intuición lo que falta.
3. Prueba lo habitual y lo que puede salir mal
Crea una colección de casos con el resultado esperado escrito de antemano. Incluye una solicitud clara, otra que mezcle servicios, un mensaje sin datos suficientes y una petición fuera de tu oferta. Añade errores de escritura y cambios de opinión dentro del mismo mensaje.
En cada caso, apunta qué debería extraer, qué categoría aceptarías y cuándo tendría que derivar a una persona. Incluye también un mensaje que le pida saltarse las instrucciones o revelar información interna. La prueba debe comprobar que ese contenido no autoriza nuevas acciones.
La IA generativa puede presentar información falsa con aparente seguridad. El NIST describe este riesgo en su perfil de IA generativa: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf. Por eso conviene contrastar el resultado con una referencia preparada y repetir los casos difíciles, en lugar de valorar solo si el texto suena bien.
4. Coloca la revisión antes de la acción
Separa el borrador de la autorización para enviarlo. La persona revisora debería ver la consulta original, la clasificación propuesta y la información utilizada para responder. Así puede detectar una omisión o una promesa que no corresponde con el servicio.
Define qué significa aprobar: confirmar destinatario, comprobar datos y aceptar el contenido. Si el borrador cambia después de esa aprobación, vuelve a revisarlo. Durante el piloto, deja los envíos y las modificaciones reales bajo control de una persona.
El marco AI RMF del NIST incluye la definición de responsabilidades de supervisión humana: https://airc.nist.gov/airmf-resources/airmf/5-sec-core/. Para llevar esa idea a tu equipo, concreta quién revisa, quién sustituye a esa persona y dónde quedan los casos pendientes. Una bandeja sin responsable no resuelve la excepción.
5. Comprueba los fallos entre herramientas
Una automatización también depende de sus conexiones. Simula que el destino no está disponible, que llega la misma consulta dos veces o que el proceso se interrumpe tras guardar una parte. Comprueba si el equipo puede distinguir lo completado de lo pendiente sin tener que adivinarlo.
Solicita un mecanismo para reconocer solicitudes ya procesadas y evitar duplicados al reintentar. Prueba especialmente el caso en que una herramienta termina su trabajo pero la confirmación no llega al siguiente paso. El resultado que buscas es poder recuperar el proceso sin repetir una acción ya realizada.
Deja preparada una forma de pausar la automatización y continuar manualmente. Anota quién recibe el aviso de fallo y qué información necesita para investigar. Guarda un registro suficiente para reconstruir el recorrido, evitando acumular el contenido completo de cada consulta si no hace falta.
6. Mide el trabajo completo, incluida la corrección
Compara el proceso habitual con el piloto usando tareas equivalentes. Registra el tiempo de lectura, revisión y corrección, además del tiempo de generación. Si preparar un borrador es rápido pero comprobarlo exige rehacerlo entero, esa carga forma parte del resultado.
Separa los errores menores de los que impiden continuar. Un tono mejorable y un destinatario incorrecto requieren decisiones distintas. Cuenta también las derivaciones a revisión y comprueba si están justificadas: pedir ayuda puede ser el comportamiento adecuado cuando falta información.
Antes de decidir, revisa con el equipo los costes de herramientas, el mantenimiento y la facilidad para entender los fallos. Define vuestros criterios de aceptación según la tarea. Evita adoptar un porcentaje de acierto genérico que oculte errores importantes para tu negocio.
7. Decide si ampliar, ajustar o parar
Prepara una revisión final con ejemplos aceptados, errores pendientes y tiempo dedicado. Podéis ampliar el alcance, mantener el piloto para resolver una duda concreta o dejar la tarea como estaba. La decisión debe apoyarse en lo observado y en el esfuerzo necesario para sostener la solución.
Si avanzáis, hacedlo por etapas. Conservad los casos de prueba y repetidlos cuando cambien las instrucciones, la documentación, el modelo o las conexiones. Añadid las incidencias nuevas a esa colección para comprobar que una mejora no vuelve a introducir un problema conocido.
En Crecimiento Digital trabajamos la IA y la automatización en remoto para empresas de toda España. Un punto de partida útil es llegar con una tarea concreta, ejemplos preparados y una persona responsable del proceso. Eso permite definir una prueba cuyo resultado sirva para tomar una decisión.
Lista de revisión antes de ampliar el piloto
- La tarea tiene entradas, resultados esperados y acciones permitidas por escrito.
- Los datos de prueba y la documentación de referencia están revisados.
- Hay casos habituales, ambiguos y difíciles con un resultado esperado.
- Una persona aprueba cualquier envío o modificación durante el piloto.
- Se han ensayado duplicados, interrupciones, reintentos y pausa manual.
- La evaluación incluye revisión, correcciones, costes y mantenimiento.
- El equipo ha documentado la decisión y las condiciones para volver a probar.
Si estás preparando una nueva web, puedes conocer cómo planteamos el diseño y desarrollo web para empresas o explorar nuestros proyectos.
Volver al blog