La IA, en tu trabajo.

De las horas facturables al resultado

La ficha oficial de Directions sitúa el 29 de octubre de 2026 la sesión de Sharka Chobot, de Neural Impact, sobre valor y precios en la era de la IA. El resumen plantea la presión sobre las horas facturables y el paso hacia modelos basados en resultados, con incertidumbre sobre el coste por consumo.

La lectura editorial de Nexo es que esa conversación necesita una prueba previa: demostrar qué mejora recibe el cliente cuando una tarea requiere menos trabajo. El método que sigue es una propuesta propia para diseñar esa prueba, no una reproducción de las diapositivas ni un resultado atribuido a la ponente.

Tres magnitudes que no conviene mezclar

Para evaluar el piloto proponemos llevar tres cuentas separadas. El tiempo disponible puede destinarse a otras tareas, pero convertirlo en euros mediante una tarifa interna no demuestra por sí solo que haya disminuido un pago.

También puede existir valor en atender más operaciones, reducir esperas o mejorar la calidad. En ese caso, conviene medir ese resultado directamente y evitar contar dos veces el mismo beneficio: como tiempo liberado y como ahorro económico independiente.

Acordar la prueba antes de empezar

El piloto debería partir de una operación concreta y de una definición compartida de trabajo terminado. Contar respuestas generadas puede ser insuficiente si el cliente necesita casos resueltos y aceptados.

Proponemos recoger estas condiciones en una ficha breve que firmen operativamente los responsables del proceso y de la evaluación.

• Situación inicial: volumen, dificultad de los casos, tiempo total y calidad del proceso actual. Incluir excepciones y trabajo que hoy se corrige manualmente.
• Resultado esperado: indicador, umbral de mejora, calidad mínima, presupuesto y periodo de observación acordados antes de ver los resultados.
• Evidencia: registrar cada caso, revisión humana, errores, reintentos, consumo y tiempo hasta su aceptación. Separar puesta en marcha, formación y mantenimiento recurrente.
• Atribución: comparar casos equivalentes y, cuando sea viable, mantener un grupo o periodo de referencia sin IA. Anotar cambios simultáneos de personal, volumen, datos o procedimiento.
• Responsabilidad: determinar quién valida la calidad, quién comprueba los costes y quién decide ampliar, ajustar o detener la prueba.

Ejemplo ficticio: revisar incidencias de inventario

Imaginemos un equipo que prepara propuestas de resolución para incidencias de inventario. Durante la prueba, un asistente genera borradores y una persona revisa cada caso. Todas las cifras siguientes son supuestos didácticos de Nexo; no describen a un cliente, un producto ni una experiencia de la ponencia.

Comparamos dos periodos de cuatro semanas con 500 casos de dificultad equivalente, aceptados con el mismo criterio de calidad. El balance recurrente del supuesto sería de 30 horas liberadas y 200 euros de gasto adicional. Si las 12 horas iniciales de configuración y formación corresponden al mismo equipo, en el primer periodo quedarían 18 horas netas.

Como en este supuesto no cambia la nómina ni desaparece ningún otro pago, el ahorro efectivo es cero. Justificar el gasto adicional exigiría demostrar qué resultado útil se obtiene al reasignar esas horas. El ejemplo no permite calcular un retorno económico positivo.

Decidir antes de negociar el reparto

El cierre del piloto debería producir una decisión respaldada por registros. Un resultado favorable en una muestra pequeña tampoco demuestra que el mismo comportamiento vaya a mantenerse con más usuarios, casos difíciles o mayor volumen.

Para Nexo, la negociación posterior debe distinguir el precio del servicio, el coste variable de uso y cualquier remuneración ligada a resultados. Si se propone compartir beneficios, hace falta acordar qué beneficio se reconoce, cómo se atribuye, qué costes se descuentan y durante cuánto tiempo se mide. El tiempo liberado solo debería convertirse en una base económica cuando ambas partes entiendan y acepten su valoración.

• Ampliar: la mejora se repite, cumple los umbrales de calidad y coste, y existe un uso verificable de la capacidad liberada.
• Ajustar: aparecen beneficios, pero la revisión, los errores, el consumo o la formación impiden alcanzar el objetivo. Cambiar una condición y repetir la medición.
• Detener: la mejora desaparece al incluir todos los costes, incumple la calidad acordada o la evidencia no permite sostener la atribución.

Alcance y disponibilidad

Este diseño es una propuesta de evaluación y no presupone una funcionalidad disponible en Business Central ni en otro producto. Antes de ejecutarlo, habría que comprobar en la documentación vigente de la solución elegida sus requisitos de acceso, licencias, regiones e idiomas admitidos, límites de uso y tarifas.

La ficha de la sesión permite situar el debate comercial, pero no sustituye esa comprobación técnica ni demuestra ahorros en una organización concreta. Para este piloto, el criterio de éxito propuesto es un resultado aceptado con calidad y coste medidos, cuya contribución pueda explicarse.