Tres fracasos documentados, antes de planificar nada
1. Lo que dice el chatbot lo dice la empresa. En el caso anterior el bot escribió que el descuento podía reclamarse con efecto retroactivo dentro de los 90 días. La propia web de la compañía, en una página estática, decía lo contrario. La conclusión del tribunal: la empresa debe asegurar con diligencia razonable que sus comunicaciones son exactas y no inducen a error.
No fue un fallo técnico, sino una contradicción entre dos fuentes propias. Mantenerlas alineadas es el tema del artículo sobre la base de conocimiento actualizada , con una rutina mensual.
2. El bot se inventó una política. En abril de 2025 el bot de soporte de una herramienta para desarrolladores —que firmaba los correos con nombre de persona— comunicó que el producto no podía usarse en varias máquinas. Esa regla no había existido nunca. Detrás había un error real: una condición de carrera estaba cerrando la sesión a los usuarios, y el bot se inventó una explicación para ello.
La respuesta del cofundador de la empresa: «Por desgracia, esta fue una respuesta incorrecta de un bot de soporte de IA de primera línea.» Lo que introdujeron después: desde entonces las respuestas de IA se marcan con claridad.
Es el caso más instructivo de los tres, porque no trabajaba a partir de una fuente mala. En la base de conocimiento simplemente no había tal regla. El bot no encontró respuesta y fabricó una.
3. Un chatbot público animaba a incumplir la ley. El chatbot que una gran ciudad ofrecía a los empresarios afirmó, entre otras cosas, que el propietario no tiene por qué aceptar un bono de vivienda, que dejar fuera al inquilino es lícito y que un negocio puede funcionar sin efectivo. Las tres cosas chocan con la normativa local.
Y el detalle más importante: el bot siguió vivo meses después de que los errores documentados se hicieran públicos. Eso no es un fracaso técnico sino organizativo: no había evaluación, no había umbral y no había criterio de apagado.
La buena noticia, con cifras, y qué hay detrás
El caso de éxito más citado es el de una gran firma de servicios financieros. Según la nota de prensa de la propia empresa, «el 98 % de los equipos de asesores ha adoptado el asistente.»
Las cifras de detalle, en cambio, salen del caso práctico del proveedor: 100.000 documentos en la base de conocimiento, 7.000 preguntas respondibles antes, y un alcance documental que subió del 20 % al 80 %.
Conviene añadir dos cosas. Una: el 98 % lo comunica la propia empresa, así que es una fuente fuerte, pero dice «ha adoptado», no «usa a diario». No es lo mismo. Otra: la cifra del 20 % → 80 % viene del material de marketing del proveedor, sin metodología: no se sabe cómo se midió.
Y la cifra que todo el mundo repite
La afirmación de que «el 95 % de los proyectos de IA fracasa» procede de un informe de 2025. Conviene saber qué hay detrás:
| Metodología | Cuántos |
|---|---|
| Entrevistas estructuradas | 52 |
| Directivos consultados en cuatro congresos | 153 |
| Iniciativas anunciadas públicamente y revisadas | 300+ |
| Periodo de investigación | enero – junio de 2025 |
No es investigación revisada por pares, y la muestra no es representativa. La cifra del titular hay que manejarla con cuidado.
De ese mismo informe sale, en cambio, un hallazgo bastante más útil —con la misma reserva, porque viene de la misma muestra—: los despliegues hechos con un socio externo tuvieron éxito en el 66 % de los casos, los desarrollos propios en el 33 %, y el uso por parte de los empleados fue más o menos el doble con las herramientas externas.
La sorpresa: empieza por la búsqueda por palabras clave
Es el consejo más discutible del artículo, pero tiene una medición detrás.
En mayo de 2026 apareció un benchmark construido expresamente sobre conocimiento interno de empresa: alrededor de medio millón de documentos de nueve fuentes —mensajes de chat, correo, gestor de tareas, repositorio documental, tickets, actas de reunión—. Quinientas preguntas, en diez categorías.
| Método | Corrección | Document recall |
|---|---|---|
| Búsqueda por palabras clave | 68,8 % | 68,4 % |
| Búsqueda por embeddings | 51,4 % | 46,0 % |
Diecisiete puntos de diferencia, a favor de las palabras clave.
La lección no es que la búsqueda vectorial sea mala, sino que el dato de empresa es bastante distinto de los benchmarks públicos sobre los que se construye casi toda la recomendación al uso. Quien empieza comprando una base de datos vectorial quizá arranque desde un punto peor que quien empieza por palabras clave y mide después cuánto añade el vector . Las mediciones de esta clase de error las reúne el post sobre hybrid search , una al lado de otra.
Los permisos: la primera decisión, no la última
Esta es la parte más cara y más subestimada, y la que falta en casi todos los planes.
El problema es sencillo: el chatbot no debe devolver nada que quien pregunta no pueda ver. La implementación no es sencilla, y la documentación de los fabricantes es inusualmente franca sobre sus límites:
CUATRO COSAS QUE DECIDIR EL PRIMER DÍA
1. NO SIEMPRE SE PUEDE ACTIVAR DESPUÉS
Hay plataformas donde la herencia de permisos
solo se configura en la primera indexación.
Después hay que construir un índice nuevo.
2. UN CAMBIO DE PERMISOS NO ES INMEDIATO
El cambio hecho en el sistema de origen solo se
ve tras la siguiente sincronización. Hay una
ventana en la que sigue valiendo el permiso viejo.
3. EL PERMISO HEREDADO SE COMPORTA DISTINTO
El permiso dado sobre el elemento se refresca en
cada pasada; el cambio HEREDADO de la carpeta o
del sitio exige un refresco aparte.
4. UN ÍNDICE CHUNKED SE CONFIGURA APARTE
El filtro definido sobre el documento no se
extiende solo a los chunks.
El segundo punto es el peligroso, y formulado como pregunta concreta suena así: ¿qué pasa cuando despiden a alguien? Si la ventana de sincronización se mide en horas, durante horas seguirá alcanzando por la base de conocimiento aquello de lo que el sistema de origen ya lo privó.
Y esta es la cláusula de responsabilidad que enuncia la propia documentación del fabricante: es responsabilidad tuya gestionar si el dato sale de los límites de cumplimiento y geográficos de tu organización, y si los permisos correctos están configurados.
¿Cuánto cuesta y cuánto tarda?
Empecemos por la parte honesta: cifras publicadas de tiempo y coste, con metodología, para un chatbot RAG de empresa no encontré. Ni de fabricante, ni de consultora, ni de investigación. Lo que circula por internet bajo el título «coste de implantarRAG » son estimaciones.
Lo que sí se puede dar desde fuente primaria son los precios de los componentes, y con ellos se puede hacer un cálculo propio.
[Cálculo propio] Supuesto: un documento medio tiene cinco páginas, en torno a 3.300 tokens en inglés. La tabla siguiente calcula todo con ese recuento en inglés; para documentos en húngaro, multiplícalo por una vez y media o el doble.
| Tamaño | Documentos | Tokens | Embedding único |
|---|---|---|---|
| Pequeño | 1.000 | 3,3 M | < 1 USD |
| Mediano | 10.000 | 33 M | ~5 USD |
| Grande | 100.000 | 330 M | ~50 USD |
El embedding sale prácticamente gratis. Esa cifra siempre sorprende.
La operación mensual tiene dos partidas. El almacenamiento y la búsqueda en un servicio gestionado rondan unos pocos dólares por gigabyte, más uno a cuatro dólares por cada mil consultas. La respuesta, en cambio, depende del modelo, y ahí está el multiplicador de veinticuatro: las mismas diez mil preguntas al mes cuestan del orden de 26 a 635 dólares según elijas el modelo más barato o el más caro.
El coste de verdad no está en ninguna de las dos: está en el trabajo humano. Preparar los documentos, mapear los permisos, montar las preguntas de prueba y hacer el mantenimiento mensual. Para eso no hay cifra publicada, pero frente a las partidas anteriores es órdenes de magnitud mayor.
¿Lo va a usar alguien?
Con franqueza: dato público y medido no hay. Una medición longitudinal publicada y con metodología sobre qué porcentaje de los chatbots internos desplegados se sigue usando unos meses después no la encontré. Las empresas no publican las curvas de uso de sus herramientas internas.
Lo que hay es una tasa de adopción del 98 % en una nota de prensa y algunas encuestas basadas en autodeclaración.
La conclusión práctica sale justo de ahí: si no hay base de comparación, tienes que medirlo tú. Desde el primer día del despliegue registra los usuarios activos semanales y el feedback pregunta a pregunta, porque después no lo puedes reconstruir y no hay cifra del sector con la que compararte.
El plan
0. DECIDE EL MODELO DE PERMISOS
Este es el PRIMER paso. Hay plataformas donde
no se puede activar después.
1. UN ÁREA ESTRECHA, 500-2000 DOCUMENTOS
Un departamento, un tipo de documento. Los casos
medidos con éxito son los bien acotados.
2. EMPIEZA POR LA BÚSQUEDA POR PALABRAS CLAVE
Y MIDE cuánto añade la parte vectorial.
Con datos de empresa ganó por 17 puntos.
3. 100-150 PREGUNTAS DE PRUEBA, CON UN EXPERTO
Pregunta, respuesta correcta y DE QUÉ documento.
Sin eso no hay contra qué medir.
4. MIDE ANTES DEL DESPLIEGUE, DOS COSAS APARTE
Si encontró el documento correcto y si lo
aprovechó bien. No es el mismo fallo.
5. FIJA UN CRITERIO DE APAGADO
Por adelantado y por escrito: la tasa de error
con la que lo paras. El chatbot público estuvo
meses fallando porque nadie fijó ninguno.
6. MARCA QUE HA RESPONDIDO UNA IA
Sin ambigüedad. Es lo que introdujo la empresa
cuyo bot se inventó una política.
7. REGISTRA EL USO DESDE EL PRIMER DÍA
Usuarios activos semanales, feedback por
pregunta. No hay benchmark del sector - mide tú.
8. NOMBRA UN RESPONSABLE
No un jefe de proyecto: alguien que lo revise.
El quinto punto es el que se deduce más directamente de los tres fracasos documentados. En ninguno de los tres casos el problema fue que el sistema se equivocara: fue que nadie había fijado por adelantado qué pasa entonces.
En lo que no sueles pensar
Cinco preguntas que merece la pena hacerse al planificar, porque todas salen caras después:
- ¿Quién responde del contenido si da una respuesta mala? Según la decisión judicial citada: la empresa.
- ¿Qué pasa cuando despiden a alguien? ¿Cuánto dura la ventana de sincronización de permisos?
- ¿Y si dos documentos se contradicen? Eso provocó el primer caso.
- ¿Cuánto mantenimiento hay, y quién lo hace?
- ¿Cuál es el listón por debajo del cual lo paras?
Malentendidos habituales
- «El chatbot es solo una ayuda, no una comunicación oficial.» La decisión judicial dice que da igual que la información venga de una página estática o de un chatbot.
- «Con una buena base de conocimiento no alucina.» En el caso citado, en la base de conocimiento no había tal regla: el bot no encontró respuesta y se inventó una.
- «Hace falta búsqueda vectorial.» Sobre documentos de empresa, la de palabras clave fue 17 puntos mejor en un benchmark de 2026.
- «Los permisos ya los resolveremos al final.» Hay plataformas donde después no se pueden activar en absoluto, y en todas hay retardo de sincronización.
- «El modelo y el almacenamiento son el coste principal.» El embedding se mide en céntimos y el almacenamiento en dólares. El modelo son de 26 a 635 dólares al mes, y el trabajo humano es una partida aún de órdenes de magnitud mayor.
- «Si sale bien, ya lo usarán.» Sobre eso no hay dato del sector. Lo que hay: las herramientas construidas con un socio externo las usó más o menos el doble de gente.
Lo que conviene llevarse
Un chatbot de conocimiento interno no es un proyecto tecnológico. Ninguno de los tres fracasos documentados fue un error del modelo: uno fue una contradicción entre dos fuentes propias, el segundo un contenido que faltaba, el tercero un criterio de apagado inexistente.
Hay tres decisiones que tomar la primera semana, y las tres son organizativas: el modelo de permisos (porque después sale caro o es imposible), el criterio de apagado (porque sin él el sistema defectuoso sigue funcionando) y el responsable (porque solo se puede hacer valer con el sistema en marcha).
Y una cifra que conviene tener en la cabeza al planificar: 812 dólares. Esa fue la indemnización en el caso que sentó precedente. La lección no es el importe, sino que la frase de tu chatbot es tu frase. Los detalles de la medición los cuenta el artículo sobre la evaluación de un sistema RAG , y los cimientos los pone el pilar sobre RAG explicado , desde cero.