Todas las agencias responden con un intervalo tan amplio que no sirve de nada, porque la respuesta sincera depende de cosas que aún no han visto. Así que aquí tienes lo que hay detrás de la cifra: qué implican las cuatro modalidades habituales de trabajo con IA, cuál necesitas y qué factores encarecen cada una.
Los costes siguientes se expresan en semanas de ingeniería, no en dinero. Las tarifas varían según el mercado y quién haga el trabajo, así que una página con precios en dólares sería errónea para la mayoría de quienes la lean. Multiplica por la tarifa que estés comparando. Son estimaciones nuestras, basadas en desarrollar este tipo de soluciones; no son un estudio del sector.
Cuatro modalidades de trabajo con IA
Casi todas las solicitudes que recibimos corresponden a una de estas modalidades o combinan dos. Identificar cuál necesitas es el mayor paso hacia una cifra real y puedes hacerlo antes de hablar con nadie.
| Modalidad | Qué hace | Hasta la primera versión en producción |
|---|---|---|
| Respuestas basadas en tu propio contenido | El personal o los clientes hacen preguntas y el sistema responde basándose en tus documentos, con citas de las fuentes. | De 4 a 8 semanas de ingeniería |
| Extracción y clasificación | Convierte facturas, correos electrónicos, tickets o formularios en campos estructurados o categorías. | De 3 a 6 semanas de ingeniería |
| Un agente que realiza una tarea | Realiza una acción en tus sistemas; no se limita a generar texto. | De 8 a 16 semanas de ingeniería |
| Un modelo integrado en tu producto | Se ejecuta en el dispositivo del usuario o en tus propios servidores, sin API de terceros. | De 10 a 20 semanas de ingeniería |
Los dos últimos intervalos son más amplios por el mismo motivo: ambos dependen de factores ajenos a la IA. La viabilidad de un agente depende de las API a través de las que debe actuar, y un modelo en el dispositivo está limitado por el hardware que hayas decidido admitir.
Qué determina realmente el precio
Para ver un flujo concreto de extracción, consulta nuestro guía sobre extracción de datos de facturas y servicio personalizado de automatización del procesamiento de facturas: recepción, validación, revisión del personal y exportación a tu sistema de contabilidad.
Ninguno de estos factores es el modelo. Evaluar las opciones de modelos lleva una semana; después, basta con indicar la elegida en un archivo de configuración. Si una propuesta lo presenta como la cuestión central, eso dice algo sobre la propuesta.
- El estado de tus datos. La variable más importante. El caso barato: documentos limpios, actualizados y bien organizados en un solo lugar. El caro: cuatro sistemas de registro con datos contradictorios, PDF escaneados y una wiki que nadie actualiza desde 2023. El trabajo consiste en poner en orden los datos, algo que habrías tenido que hacer de todos modos.
- El nivel de precisión necesario. Hay una gran diferencia entre «redacta algo que una persona revisa» y «actúa sin supervisión». La segunda opción requiere medición, gestión de fallos y una forma de equivocarse sin causar daños; ahí es donde se va el presupuesto.
- Cuántos sistemas intervienen. Cada integración tiene su propia autenticación, sus propios límites de solicitudes y sus propios casos de error. Dos son lo habitual. Seis ya es otro proyecto.
- Si alguien se encargará de la evaluación. Si nadie de tu equipo puede decir si una respuesta es buena, primero tendremos que crear los medios para evaluarla. Vale la pena hacerlo, pero no es gratis.
- Adónde pueden ir los datos. «Nada sale de nuestra infraestructura» es una restricción válida y un factor que debe tenerse en cuenta en el diseño. Normalmente implica alojar modelos de pesos abiertos, lo que supone sacrificar parte de la capacidad a cambio de control y asumir los costes de alojamiento.
El coste de funcionamiento que la gente olvida
El presupuesto de desarrollo no es el presupuesto total. Hay tres costes que continúan después del lanzamiento y, normalmente, solo el primero está previsto.
- Uso. Coste por solicitud, que aumenta con el volumen. Es bajo durante el piloto, por lo que sorprende cuando se alcanza el volumen de producción. Conviene calcularlo con un volumen diez veces superior al del piloto antes de decidir la arquitectura.
- Evaluación y supervisión. La calidad cambia a medida que se actualiza tu contenido y los proveedores modifican los modelos. Alguien tiene que detectar esos cambios.
- Cambios de proveedor. Los proveedores dejan de ofrecer modelos según su propio calendario. Prevé unos días de trabajo al año para cambiar de modelo y evita diseños que dificulten hacerlo.
Cuánto debería costar y demostrar una prueba de concepto
De dos a cuatro semanas. Si dura más, no es una prueba de concepto: es un proyecto sin plan.
Lo importante es su objetivo. Una prueba de concepto debe terminar con una decisión, no con una demo. Para asegurarte, define antes de empezar la cifra que determinará el éxito y qué harás si no se alcanza. «Debe clasificar correctamente al menos el 85 % de los tickets; si no, paramos» es una prueba de concepto. «Veamos qué podría hacer la IA por nosotros» es un taller.
También debería producir algo que seguirás necesitando después: un conjunto pequeño y real de ejemplos etiquetados con las respuestas correctas. Ese conjunto de prueba seguirá siendo útil aunque cambie el modelo y permitirá tomar la siguiente decisión con menos coste.
Preguntas que conviene hacerle a cualquier proveedor
- 1. ¿Qué podría hacer que el coste duplicara su estimación?
- 2. ¿Cómo sabremos, con una cifra, si funciona y quién lo medirá?
- 3. ¿Cuánto costará al mes con un volumen diez veces mayor que el del piloto?
- 4. ¿Qué pasará cuando dejen de ofrecer el modelo elegido?
- 5. ¿Adónde van nuestros datos y qué se conserva?
- 6. ¿Qué hace el sistema cuando no sabe la respuesta?
- 7. ¿Quién será el propietario del código, las instrucciones y el conjunto de evaluación al final?
La sexta pregunta es la más reveladora. Un sistema que no tenga una respuesta para ella inventará algo con seguridad, y así es como estos proyectos pierden la confianza de quienes deberían usarlos.
Cuándo no conviene desarrollarlo
Tres situaciones en las que te aconsejaríamos no hacerlo, porque decirlo pronto nos ahorra dinero a ambos.
- El proceso no está documentado en ningún sitio. Si nadie puede describir las reglas, el proyecto empieza por el trabajo de operaciones, no por la IA.
- Ocurre diez veces al mes. Automatizar una tarea poco frecuente rara vez compensa el coste de mantener la automatización.
- Ya existe un producto que lo hace. Si tus datos no son lo que te diferencia, compra una solución. Preferimos decírtelo antes que cobrarte por reconstruirla.
Cómo trabajamos
Somos un equipo pequeño de ingenieros, no una agencia: hablas con quienes escriben el código, no hay gestores de cuentas de por medio y seleccionamos cuidadosamente los proyectos que aceptamos. En el ámbito de la IA, eso incluye integraciones con LLM, búsqueda en tu propio contenido, agentes e implementación de modelos alojados por ti, además del trabajo con .NET, Python, TypeScript y servicios en la nube que realiza el resto del estudio.
También desarrollamos nuestro propio software para Windows, incluido un asistente de texto que ejecuta un modelo de lenguaje íntegramente en el PC del usuario, así que para nosotros el uso en el dispositivo y las restricciones de privacidad no son algo teórico.
Cuéntanos qué quieres desarrollar
Describe el problema, no la solución: qué hace alguien hoy, con qué frecuencia y cuánto cuesta que algo salga mal. Recibirás una respuesta en un día laborable, con el alcance y una cifra, o con una explicación de por qué creemos que no deberías desarrollarlo.