Una guía para presupuestar un proceso concreto con IA y comparar alcance, inversión, consumo y operación con una primera entrega medible.
Automatizar un proceso con IA cuesta lo que exige convertir una tarea real en un sistema que el equipo pueda usar, comprobar y mantener. En el presupuesto entran el análisis del proceso, los datos, las integraciones, las pruebas y la operación. El consumo del modelo es una parte de esa cuenta.
Para preparar una inversión de 2027, conviene elegir primero un recorrido concreto: qué entra, qué trabajo se realiza, quién decide y qué resultado debe quedar registrado. «Queremos incorporar IA» abre muchas conversaciones. «Queremos preparar solicitudes de presupuesto sin volver a copiar los mismos datos» permite empezar a calcular.
Esta guía de planificación está revisada en octubre de 2026. Los números del ejemplo son supuestos ilustrativos, no tarifas de CODE-IA ni una media del mercado. Si necesitas delimitar el trabajo, el servicio de optimización de procesos con IA empieza por el funcionamiento actual y el cuello de botella que merece la pena resolver.
La guía general sobre cuánto cuesta implementar IA en una empresa reúne las capas de inversión y referencias públicas. Esta edición para 2027 desarrolla el presupuesto de un proceso concreto, desde su primera tarea hasta la revisión y la operación.
Elige una tarea con un inicio y un final reconocibles. Puede comenzar cuando llega una solicitud y terminar cuando una persona aprueba una respuesta y queda registrada en el CRM. Entre ambos puntos habrá lecturas, comprobaciones, decisiones, cambios de estado y excepciones.
Describe quién realiza cada paso, con qué herramienta y qué información necesita. Cuenta también las esperas: localizar un documento, pedir un dato que falta o volver a revisar una versión. A veces el mayor ahorro aparece al ordenar el recorrido antes de automatizarlo.
Hay una pregunta especialmente útil para la primera reunión: ¿qué parte del trabajo seguiría siendo un problema aunque el modelo fuera gratuito? La respuesta suele señalar las integraciones, los datos y las decisiones que realmente condicionan el proyecto.
| Partida | Qué incluye | Qué conviene recibir |
|---|---|---|
| Análisis del proceso | Recorrido actual, excepciones, línea base y alcance | Un problema definido y una primera entrega comprobable |
| Datos y conocimiento | Fuentes, preparación, permisos, versiones y búsqueda cuando proceda | Un inventario de información utilizable y de sus límites |
| Integraciones y desarrollo | Conexiones, reglas, estados, registros y tratamiento de errores | Un flujo que funcione con los sistemas acordados |
| Pruebas y adopción | Casos representativos, revisión, instrucciones y aceptación | Evidencia de funcionamiento y un equipo capaz de operarlo |
| Operación | Consumo, alojamiento, supervisión, soporte y cambios | Responsables, costes recurrentes y procedimiento ante fallos |
Pide que cada partida nombre sus supuestos. No es lo mismo recibir documentos limpios y una API preparada que descubrir carpetas duplicadas y un sistema que solo permite exportaciones manuales. Ambos proyectos pueden tener el mismo formulario de entrada y costes muy distintos.
Un proceso puede mejorar con reglas convencionales, una integración, asistencia de IA o una combinación. Reservar el modelo para interpretar información variable permite mantener controles sencillos donde las reglas ya son claras.
Por ejemplo, clasificar una solicitud abierta puede requerir interpretación. Comprobar que lleva un identificador, respetar un estado aprobado o impedir un envío duplicado son reglas que conviene definir de forma explícita. Elegir bien esa frontera ayuda a estimar y probar el sistema.
También hay diferencia entre preparar un borrador y ejecutar una acción. Una ayuda para redactar una respuesta necesita revisión del contenido. Un flujo que además actualiza el CRM o envía la respuesta necesita permisos, comprobaciones y recuperación para esas acciones. El presupuesto debe reflejarlo.
Entrada y datos necesarios
Reglas, fuentes y asistencia
Decisión y excepciones
Resultado y seguimiento
Imaginemos un equipo que prepara respuestas a solicitudes comerciales. Una primera entrega podría reunir los datos recibidos, localizar documentación autorizada y proponer un borrador. La persona responsable revisa el resultado y decide qué enviar. El registro conserva el estado y la referencia necesaria para continuar.
Ese alcance ya permite medir tiempo de preparación, correcciones y solicitudes que requieren intervención adicional. Enviar automáticamente todas las respuestas sería otra decisión, con otros criterios de aceptación. Conviene presupuestarla como tal.
Haz una lista de los sistemas que intervienen y del propietario de cada dato. ¿La ficha de cliente está en el CRM? ¿Las condiciones comerciales vienen del ERP? ¿Los documentos aprobados tienen una ubicación y una versión reconocibles? ¿Quién puede autorizar una conexión?
Después, escribe qué debe ocurrir cuando una conexión falla. Una solicitud puede quedar pendiente, volver a intentarse o pasar a revisión. El sistema debe distinguir esas situaciones de una ejecución completada. Un mensaje bonito en pantalla no sustituye un estado operativo claro.
El servicio de integraciones de IA con los sistemas de la empresa permite concretar esas dependencias. Pide que la propuesta separe las conexiones disponibles, las adaptaciones necesarias y el trabajo que corresponde a otros proveedores.
Una carpeta compartida puede contener documentos útiles y, al mismo tiempo, versiones contradictorias, archivos retirados o información que ciertos usuarios no deben consultar. El presupuesto debe identificar qué material se incorporará y quién puede decidir sobre él.
Si el sistema necesita recuperar conocimiento, acuerda cómo se reconocerá una fuente vigente y qué ocurrirá cuando no haya evidencia suficiente. Una respuesta con apariencia convincente no debería contarse como éxito si utiliza una condición comercial antigua o atribuye información al cliente equivocado.
Incluye un mecanismo de actualización: quién sustituye los documentos, cómo se comprueba el cambio y qué debe revisarse en el sistema. Esa responsabilidad continúa después de la demostración inicial y afecta al coste de mantenimiento.
Supongamos, únicamente para hacer las cuentas, una primera entrega presupuestada en 9.000 € y unos compromisos recurrentes de 250 € al mes entre herramientas, infraestructura y soporte definido. El primer año sumaría 12.000 € antes de impuestos, trabajo interno, cambios adicionales y consumo variable no incluido. Estos importes son inventados; debes sustituirlos por propuestas y condiciones reales.
Ahora calcula el uso previsto. Anota ejecuciones mensuales, longitud aproximada de la información, tareas realizadas por cada ejecución y revisiones necesarias. Pide al proveedor un escenario habitual y otro de mayor carga, explicando qué cargos dependen del volumen.
Una cuota pequeña por uso puede convivir con una integración exigente. También puede ocurrir lo contrario: una puesta en marcha sencilla con una operación frecuente que requiera seguimiento. Para decidir, necesitas las dos partes de la cuenta.
Parte de una línea base observada, aunque sea una muestra pequeña y bien descrita. Mide cuánto tarda el trabajo, qué errores aparecen y cuántas veces hay que rehacerlo. Registra el periodo y el tamaño de la muestra para no convertir una impresión en una cifra aparentemente exacta.
Después, cuenta el tiempo de revisión y las excepciones que permanecen. Si una tarea pasara hipotéticamente de veinte a ocho minutos de trabajo humano, el ahorro sería de doce minutos por ejecución. Con cien ejecuciones serían veinte horas. Eso sería una hipótesis que validar, no un resultado demostrado del proyecto.
Decide cómo se utilizaría ese tiempo: atender más solicitudes, reducir una espera o evitar trabajo fuera de horario. La capacidad liberada no equivale automáticamente a dinero recuperado. La guía sobre cómo medir el ROI de una iniciativa de IA ayuda a explicar qué cambio operativo produce valor y cómo comprobarlo.
Un piloto necesita un alcance, unos casos y una decisión de salida. Puede servir para comprobar si el material permite preparar borradores útiles, si una integración responde como se esperaba o si la revisión humana cabe en el recorrido de trabajo.
Pide ejemplos representativos y excepciones: datos incompletos, una referencia desconocida, documentación contradictoria o un sistema externo temporalmente inaccesible. Acuerda qué resultado es aceptable para cada caso y cuándo debe intervenir una persona.
Al finalizar, deberías recibir lo observado, lo que sigue sin resolver y una propuesta de siguiente paso. Un piloto puede justificar continuar, cambiar el alcance o detener la iniciativa. La guía para pasar un piloto de IA a producción desarrolla los controles y responsabilidades de esa siguiente entrega.
Antes de cerrar el alcance, recorre con las personas usuarias una solicitud habitual y otra difícil. Pregunta qué comprueban de memoria, qué dato les hace desconfiar y en qué punto piden ayuda a un compañero. Ese conocimiento rara vez cabe entero en el diagrama inicial.
Si una automatización devuelve un borrador rápido pero obliga a consultar tres herramientas para revisarlo, parte del esfuerzo solo ha cambiado de sitio. Incluye la revisión en las pruebas y pide que el equipo pueda entender las fuentes, corregir el resultado y continuar cuando falte información.
Ese pequeño ensayo ayuda a elegir una entrega que encaje en el trabajo diario. También identifica formación, documentación o cambios de procedimiento que deberían tener espacio en el presupuesto.
Coloca ambas sobre el mismo recorrido. Marca quién aporta los datos, qué sistemas se conectan, qué acciones se ejecutan y qué revisión permanece en manos del equipo. Comprueba también los registros, las pruebas, el soporte y la entrega de documentación.
Imagina que una propuesta incluye preparar un borrador en una interfaz y otra añade la lectura del CRM, una validación y el registro de la decisión. La diferencia de precio puede responder a una diferencia de producto. Pide que esa diferencia quede escrita antes de comparar totales.
Revisa la continuidad: acceso a la configuración, cuentas de los servicios, propiedad de los componentes acordados y procedimiento para cambiar de proveedor. Las condiciones de terceros deben aparecer identificadas. El sistema debe quedar comprensible para quien se encargue de mantenerlo.
En esas condiciones puede ser más útil empezar por una auditoría de oportunidades de IA. Su entrega debería aclarar procesos, dependencias y prioridades, para que el siguiente presupuesto responda a un trabajo identificable.
Prepara el recorrido actual, los sistemas implicados, la frecuencia aproximada y un ejemplo anonimizado o ficticio que conserve la estructura del trabajo. Explica qué duele más: tiempo, errores, esperas o falta de información. Añade quién revisará el resultado y qué restricciones de acceso o uso deben respetarse.
No necesitas resolver previamente toda la arquitectura. Sí conviene traer suficiente contexto para que el proveedor pueda distinguir una integración sencilla de un proyecto de datos, y una ayuda de redacción de una automatización que toma acciones sobre sistemas reales.
Una primera entrega puede resolver una parte del recorrido con revisión humana y dejar el resto documentado. Elige esa frontera por utilidad y capacidad de comprobación, y explica el trabajo que seguirá siendo manual.
Debe explicar cómo se operará el sistema. Separa consumo, herramientas, supervisión, soporte y cambios. Puedes contratarlos de distintas formas, pero todos necesitan un responsable y unas condiciones claras.
La revisión debe mostrar los resultados y las dependencias pendientes para decidir si continuar, cambiar el planteamiento o detenerlo. Conviene acordar ese criterio antes de empezar.
Si quieres aterrizar la inversión, cuéntanos qué proceso quieres mejorar con IA. Empecemos por una tarea que el equipo reconozca y un resultado que pueda comprobar. El presupuesto será bastante más útil que una promesa de automatizarlo todo.
Comparte el recorrido actual, los sistemas implicados y el resultado que necesita el equipo.