Cómo elegir tu primer proyecto de IA empresarial

Elige una tarea con un responsable y un resultado observable

Describe qué recibe hoy una persona, qué información consulta y qué entrega después. «Incorporar IA» o «crear un asistente» no define el trabajo que se evaluará. Una tarea como preparar una respuesta sobre un procedimiento tiene entradas, fuentes y un resultado que alguien puede revisar.

Compara las ideas por utilidad, fuentes disponibles, consecuencias del error y capacidad de revisión. Elige un responsable que conozca el proceso y decida qué respuestas son aceptables. Si faltan fuentes o nadie puede evaluar la salida, deja esa idea pendiente y aclara primero esas condiciones.

• Problema: qué tarea necesita apoyo y qué dificultad concreta se observa.
• Resultado: respuesta, clasificación, borrador o acción que se quiere evaluar.
• Responsable: quién valida la calidad y resuelve las excepciones del proceso.

Compara IA, reglas y una mejora del proceso

Pregúntate qué decisión requiere interpretar lenguaje o antecedentes variables y qué parte puede describirse con condiciones conocidas. Un registro incompleto quizá necesite un formulario mejor; una transferencia de datos puede requerir una integración. Compara esas alternativas antes de atribuir todo el problema a la falta de IA.

Si eliges IA para preparar respuestas, separa la preparación del envío o cambio en otro sistema. Identifica qué partes usan el modelo y cuáles dependen de reglas, fuentes o personas para evaluar cada componente y reconocer sus fallas.

Ejemplo hipotético: preparar respuestas a consultas internas

Imagina un equipo que recibe consultas sobre procedimientos dispersos en documentos. Este ejemplo es hipotético; no representa un cliente ni resultados de Digital Dev. La primera tarea propuesta es preparar un borrador con la fuente utilizada para que una persona lo revise. En esta evaluación el asistente no cambia registros ni envía respuestas por su cuenta.

El conjunto de prueba incluye consultas respondidas por un documento vigente, preguntas ambiguas, versiones contradictorias y solicitudes sin respaldo. El equipo espera una respuesta trazable cuando existe información suficiente, y una petición de aclaración o derivación cuando falta. Si las fuentes están desactualizadas, corregirlas forma parte del trabajo pendiente; cambiar de modelo no sustituye esa revisión.

Reúne las evidencias antes de probar

Prepara ejemplos que representen el trabajo habitual y también sus excepciones. Conserva una referencia de cómo se resuelven hoy, incluyendo la revisión necesaria. Usa muestras ficticias o anonimizadas para la conversación inicial y acuerda por separado los accesos que necesita el proyecto.

• Solicitudes representativas y salidas esperadas, con explicación de por qué se consideran correctas.
• Inventario de fuentes: responsable, vigencia y condiciones de acceso de cada una.
• Mapa de herramientas: qué se puede consultar y qué acciones requieren autorización.
• Casos difíciles: información ausente, ambigüedad, contradicciones y fallas de conexión.
• Referencia del trabajo actual: calidad, esfuerzo de revisión y problemas observados.

Define qué puede hacer y cuándo debe detenerse

Escribe los límites como comportamientos comprobables. Por ejemplo: consultar solo las fuentes autorizadas para ese usuario, pedir revisión antes de modificar un registro y comunicar que una acción quedó pendiente si falla la conexión. Una descripción como «agente seguro» no permite verificar esas condiciones.

Acuerda quién revisa las excepciones, cómo se detiene el flujo y qué registro permite investigar lo ocurrido. Revisa también qué información recibe cada proveedor y sus condiciones de uso, retención y acceso con las personas responsables en tu organización. Cada conexión necesita una comprobación propia; mostrar una demostración no confirma que tu sistema esté integrado.

Acordar criterios antes de evaluar y decidir después

Define qué casos deben aprobarse, qué errores impiden continuar y quién decide sobre resultados dudosos. Mantén identificada la configuración evaluada y reserva ejemplos para una comprobación posterior a los ajustes. Revisar solo las respuestas que se usaron para corregir el asistente deja preguntas importantes abiertas.

Compara el resultado con la referencia del proceso actual. Incluye la calidad de la salida, la revisión humana, el tiempo de atención y los componentes del costo de uso. No establezcas un porcentaje de éxito arbitrario: el criterio debe responder al efecto de cada error y a las condiciones acordadas para la tarea.

• Continuar: los casos cumplen los criterios y existen responsables de operación.
• Ajustar: la evidencia identifica un problema acotado y una nueva comprobación posible.
• Detener: faltan fuentes, permisos o calidad para operar dentro del alcance previsto.

Documenta la decisión y prepara el siguiente paso

Registra la tarea, fuentes, configuración, ejemplos evaluados, fallas y decisión. Antes de ampliar el uso, comprueba los cambios: permisos, preguntas y responsabilidades de soporte. Aceptar una tarea no demuestra que el asistente esté preparado para cualquier otra.

El caso Sabioncello documenta trabajo de Kactus, parte del ecosistema Digital Dev, en atención y agendamiento con IA y seguimiento humano. Permite conocer un alcance concreto; tu evaluación tiene sus propias evidencias. Completa el brief con la tarea y las condiciones pendientes de confirmar.