Cuando una empresa pide presupuesto para «implantar inteligencia artificial», la respuesta honesta es que todavía no hay presupuesto que dar. El coste de un sistema de IA no lo determina el modelo que se elija, ni la plataforma de moda, ni el número de prompts. Lo determinan tres cosas bastante menos atractivas: qué proceso se va a tocar, en qué estado están los datos que alimentan ese proceso y cuántos sistemas hay que conectar para que la respuesta sirva de verdad.

Por eso dos proyectos que suenan igual en una reunión pueden diferir en un factor de diez. «Queremos un chatbot que consulte nuestra documentación» puede significar un buscador sobre 2.000 PDFs homogéneos con una interfaz web, o un asistente que cruza expedientes en tres repositorios distintos, respeta permisos por departamento y devuelve citas verificables. El primero se puede cerrar en semanas. El segundo es un proyecto de ingeniería con fases, pruebas y mantenimiento.

El error de presupuestar por tecnología

Los pliegos y las peticiones que llegan suelen estar redactados en clave de herramienta: «queremos un agente», «queremos RAG», «queremos un copiloto». Es comprensible, porque es el vocabulario que circula, pero no permite calcular nada. La unidad de medida del coste no es la tecnología, es el trabajo previo y las condiciones de contorno.

Un ejercicio útil es traducir la petición a cuatro preguntas antes de hablar de dinero. Cuántos documentos o registros entran en juego y en qué formatos. Quién puede ver qué dentro de la organización. Qué decisión se toma con la respuesta del sistema y qué ocurre si esa respuesta es incorrecta. Y qué sistemas tienen que actualizarse como consecuencia. Cuando esas cuatro respuestas están sobre la mesa, el presupuesto se puede discutir. Antes, no.

Las seis partidas que componen el coste real

1. Diagnóstico y definición del alcance

Es la fase que más dinero ahorra y la que más se recorta. Consiste en recorrer el proceso real, no el del organigrama, identificar quién hace qué y localizar dónde se pierden horas. Aquí se decide si el problema se resuelve con IA, con una automatización determinista o simplemente reordenando un flujo de trabajo.

Una parte relevante de los proyectos que llegan a nuestra mesa se caen en esta fase, y eso es una buena noticia: mejor descubrirlo con un análisis de dos semanas que con un desarrollo de cuatro meses. El entregable no es un documento de cuarenta páginas, es un alcance cerrado, un criterio de éxito medible y una estimación defendible.

2. Preparación del dato

La partida que nadie quiere pagar y que decide el resultado. Incluye inventariar las fuentes, eliminar duplicados y versiones obsoletas, aplicar reconocimiento óptico de caracteres a los documentos escaneados, normalizar formatos, definir la fragmentación del texto y, sobre todo, resolver los permisos.

El apartado de permisos es el que suele romper las estimaciones. Un buscador que devuelve el expediente de un cliente a quien no debería verlo es un incidente de seguridad, no un fallo de calidad. Si el sistema no puede heredar la estructura de acceso del repositorio original, hay que construirla, y eso es desarrollo, no configuración.

3. Construcción de la capa de IA

Aquí entra lo que la gente identifica con «hacer IA»: el pipeline de recuperación, la elección del modelo, la generación de embeddings, la construcción del índice vectorial, la búsqueda híbrida que combina semántica y coincidencia exacta, y la plantilla de respuesta con citas.

En términos de esfuerzo, es menos pesado de lo que sugiere su protagonismo mediático. Con un stack sensato, un motor de consulta documental funcional se levanta en pocas semanas. Lo que lleva tiempo es afinarlo: ajustar cuántos fragmentos se recuperan, cómo se pondera la búsqueda léxica frente a la vectorial, cómo se evita que el modelo responda cuando la documentación no contiene la respuesta.

4. Integración con los sistemas existentes

La partida que más se subestima cuando la empresa tiene ERP, CRM o un sistema de gestión propio. Un buscador accesible por web es una cosa; un asistente que consulta el stock real, cruza el histórico de un cliente o genera un borrador dentro de la herramienta que el equipo ya usa es otra completamente distinta.

El coste depende casi por completo de la calidad de las interfaces disponibles. Una API documentada y estable convierte la integración en un trabajo acotado. Una base de datos antigua sin documentación, con reglas de negocio escondidas en procedimientos almacenados, puede consumir más horas que toda la capa de IA junta.

5. Evaluación, seguridad y puesta en producción

Un sistema que responde bien en una demo con veinte documentos no está validado. La evaluación consiste en construir un conjunto de preguntas representativas con sus respuestas correctas, medir cuántas acierta, cuántas cita mal y cuántas inventa, y repetir esa medición cada vez que se toca el sistema.

A esto se suman los controles de seguridad: registro de auditoría de cada consulta, límites de uso, gestión de credenciales, protección frente a inyección de instrucciones en documentos y revisión del tratamiento de datos personales. En España, además, hay que valorar la evaluación de impacto relativa a la protección de datos cuando se trata información de personas, y encajar el sistema en el marco del Reglamento europeo de IA según el uso previsto.

6. Operación y mantenimiento

La partida que casi nunca aparece en la propuesta inicial y que existe todos los meses siguientes. Un sistema RAG no es un producto terminado: la documentación cambia, entran nuevos formatos, se actualizan las versiones del modelo, hay que reindexar, revisar consultas fallidas y ajustar.

Si nadie asume ese mantenimiento, el sistema se degrada en silencio. A los seis meses responde con documentación antigua y el equipo deja de confiar en él. Conviene presupuestarlo desde el primer día, aunque sea como una bolsa de horas mensual.

Por qué el coste por token es la partida menos relevante

Las conversaciones sobre coste suelen empezar por el precio del modelo, y es un punto de partida engañoso. En un sistema corporativo con volumen moderado, el gasto en inferencia es una línea menor frente al coste de ingeniería y de preparación del dato. Un asistente interno con cien consultas diarias no arruina a nadie por tokens; lo que cuesta es que alguien lo mantenga.

La elección entre modelo en la nube y modelo local no se decide por precio unitario, sino por tres factores. El primero es la confidencialidad: si la documentación no puede salir del perímetro, la nube pública queda descartada y hay que asumir hardware o una nube privada. El segundo es la previsibilidad: un modelo local tiene un coste fijo mensual y un rendimiento variable según la máquina; una API tiene coste variable y rendimiento gestionado por el proveedor. El tercero es la salida: depender de un proveedor concreto para el modelo y para los embeddings complica el cambio posterior.

Sobre esto último conviene ser explícito en cualquier presupuesto: quién es dueño del código, dónde vive el índice y qué cuesta migrar si el proveedor cambia sus condiciones. Son preguntas que rara vez aparecen en la primera reunión y que determinan el coste a tres años.

Órdenes de magnitud de esfuerzo según el tipo de proyecto

Las cifras siguientes no son tarifas ni compromisos: son bandas de esfuerzo de ingeniería que sirven para comparar alternativas antes de pedir ofertas. Varían con el estado de los datos y de las integraciones, que es precisamente lo que hay que auditar.

  • Buscador documental interno sobre documentación homogénea (entre 5.000 y 50.000 documentos en formatos razonablemente limpios, interfaz web, citas verificables): del orden de 8 a 15 semanas-persona, más una bolsa mensual de operación.
  • Extracción estructurada de documentos (facturas, albaranes, partes de trabajo) con volcado a un sistema de gestión: entre 6 y 12 semanas-persona, con una fase de validación humana imprescindible al principio.
  • Aplicación corporativa con IA integrada en ERP o CRM (consultas en lenguaje natural sobre datos de negocio, permisos heredados, trazabilidad): a partir de 20 semanas-persona, y aquí el cuello de botella casi siempre es la integración, no el modelo.

La lectura correcta de estas bandas no es «cuánto me va a costar», sino «qué parte del presupuesto se va en el dato y en la integración». Si una propuesta promete el tercer escenario en el tiempo del primero, o ha entendido mal el problema o está dejando fuera trabajo que aparecerá después.

Las partidas que aparecen a mitad de proyecto

Hay una serie de costes que casi nunca están en la oferta inicial y que conviene poner sobre la mesa desde el principio. El más habitual es el saneamiento de datos que se descubre al abrir los documentos. El segundo es el reconocimiento óptico de imágenes en archivos escaneados de baja calidad. El tercero es el sistema de permisos, que suele requerir trabajo específico.

También aparecen la formación del equipo, la adaptación de los procedimientos internos para que el sistema se use de verdad, y la evaluación continua. Y un coste organizativo que no se factura pero se nota: alguien dentro de la empresa tiene que ser el dueño funcional del sistema, decidir qué documentación es la buena y validar las respuestas cuando hay dudas.

Cómo leer un presupuesto de IA sin equivocarse

  • Alcance cerrado por fases. Una primera fase de diagnóstico con entregable concreto, una segunda de construcción sobre un caso acotado. Desconfía de propuestas que empiezan por una plataforma y dejan el caso de uso para más adelante.
  • Criterios de aceptación explícitos. No «el sistema funcionará correctamente», sino un conjunto de preguntas de referencia con un umbral de acierto acordado y una forma de comprobarlo.
  • Qué pasa si el dato está sucio. Si la propuesta no menciona la calidad del dato, ese trabajo lo vas a pagar igual, solo que sin presupuesto aprobado.
  • Propiedad y salida. Código en un repositorio tuyo, documentación de arquitectura y un procedimiento claro para llevarte el índice y los embeddings si cambias de proveedor.
  • Coste recurrente separado. Infraestructura, mantenimiento y consumo de modelos, cada uno con su cifra, no todo mezclado en una cuota mensual opaca.

Cinco preguntas antes de firmar

¿Qué proceso concreto se va a medir y con qué indicador? ¿Cuántos documentos o registros entran en el alcance y quién decide cuáles son válidos? ¿Cómo se comprueba que una respuesta es correcta y qué pasa cuando el sistema no lo sabe? ¿Quién mantiene esto dentro de un año? ¿Qué parte del sistema es estándar y qué parte es desarrollo a medida que habrá que sostener?

Si las respuestas son claras, el número final del presupuesto importa menos de lo que parece: sabrás qué estás comprando. Si no lo son, cualquier cifra es una hipótesis.

Si quieres contrastar el orden de magnitud de un caso concreto, podemos revisar el volumen y el estado de tu documentación y decirte en qué banda de esfuerzo cae. Ese análisis es el que convierte una idea en un proyecto de IA con alcance y presupuesto.