Skip to content
Ideasforge
EN
Servicios Proyectos Quiénes somos Blog Contacto

Servicios

Guía: agentes de IA Desarrollo de agentes de IA Automatización de procesos con IA Agentes conversacionales Documentación interna Qué cuesta un agente de IA IA para pymes IA para inmobiliarias IA para gestorías
Somos la forja de tus ideas

Deja de buscar en tus sistemas. Agentes de IA que responden y actúan.

En Ideasforge diseñamos y mantenemos agentes de IA a medida para medianas y grandes empresas, sobre tu infraestructura y medidos antes de cada cambio.

Cuéntanos tu reto

Empresas con las que trabajamos

Industria, agricultura, inmobiliaria, salud y servicios profesionales.

  • Stanton
  • The Dazzwebs Studio
  • AIMO
  • Barceloneta Premium
  • Savian
  • Baba
  • Wazzy
  • Amigo & Amigo
Empresa industrial

Diagnóstico guiado para quien está delante de la máquina

6 agentes
Diagnóstico guiado para quien está delante de la máquina
Savian

Cualquiera del equipo, preguntando a sus datos

De horas a segundos
Cualquiera del equipo, preguntando a sus datos
Stanton

Las facturas dejaron de teclearse

2 agentes
Las facturas dejaron de teclearse
Barceloneta Premium

El filtro que trabaja mientras la oficina está cerrada

+3 horas
El filtro que trabaja mientras la oficina está cerrada
Wazzy

Reservar cita sin llamar ni esperar

103 controles
Reservar cita sin llamar ni esperar

Servicios

Lo que construimos

Cuatro capacidades para medianas y grandes empresas. Para pymes, las mismas piezas en paquetes cerrados.

Para medianas y grandes empresas

Para pequeñas y medianas empresas

Cuéntanos tu reto

Compromisos

¿Por qué Ideasforge?

Tres compromisos que no vienen en una suscripción.

  • Observabilidad por defecto

    Cada cambio pasa por una batería de pruebas antes de publicarse y después seguimos midiendo cada semana. Si algo deja de entender bien una consulta, nos enteramos antes que tú.

  • El código es tuyo

    Te entregamos el sistema, no una caja negra. Si mañana decides llevártelo a otro proveedor, puedes.

  • Seguridad por defecto

    El modelo no escribe las consultas que llegan a tus sistemas, elige entre opciones que ya hemos revisado. Cada persona entra con su cuenta de empresa y tus datos viven donde tú decidas.

Medimos cada cambio antes de que llegue a producción

Tu proveedor actualiza el modelo sobre el que corre tu sistema sin cambiarle el nombre, tu documentación no para de crecer y el sistema que ayer respondía bien hoy empieza a responder mal.

Cuéntanos tu reto
  • Pruebas antes de publicar Si un cambio empeora la calidad, no llega a tus usuarios.
  • Sabemos por qué respondió eso Queda registrado qué consultó y qué descartó.
  • Contamos lo que no supo hacer Cada pregunta sin respuesta se anota con su motivo.
  • Vigilamos al proveedor Si actualiza el modelo por su cuenta, lo notamos nosotros primero.
  • Avisa cuando va incompleto Dice qué ha consultado y qué se ha dejado fuera.

El fallo más caro no hace saltar ninguna alarma, es una respuesta impecable (pero falsa).

El fallo que no parece un fallo

Un responsable pregunta cuánto se produjo el mes pasado en la finca 4. El asistente contesta una cifra con buena pinta y bien redactada. Esa cifra está mal. En los registros no aparece ningún error. El sistema hizo exactamente lo que creía correcto. Ese es el fallo que nos quita el sueño, porque no se parece a un fallo.

El suelo se mueve solo

Lo desconcertante es que el nombre del modelo no cambia mientras lo que hay detrás sí. Investigadores de Stanford y Berkeley lo midieron en 2023. Pasaron las mismas preguntas al mismo modelo comercial en marzo y en junio, llamándolo igual desde la misma conexión. En una de las tareas, el acierto cayó del 97,6 % al 2,4 %. Nadie del lado del cliente tocó nada. El proveedor había actualizado el modelo por debajo. Por eso medir no es una manía nuestra, es la única forma de saber que lo que funcionaba en marzo sigue funcionando en junio.

Por qué podemos guardar la decisión

Contra eso no sirve mirar los registros de error, porque no hay error que mirar. Y aquí es donde nuestra forma de construir cambia las cosas. Si la decisión vive dentro del modelo, no hay nada que guardar, solo un texto que salió. Por eso en nuestros sistemas el modelo no decide. Entiende la pregunta y entrega un contrato en JSON con lo que ha entendido. Es un script quien lo valida, decide y responde. Esa decisión sí se puede guardar entera: qué entendió, qué pidió, qué descartó el validador y por qué. Lo contamos en detalle en por qué no nos gustan las arquitecturas agénticas.

Cómo lo hacíamos mal

Al principio revisábamos a mano las decisiones del modelo, una por una, leyendo ejecuciones a posteriori. No escalaba y tampoco servía como referencia, porque un sistema que no es determinista no responde dos veces igual. Revisar casos sueltos no te dice si el conjunto ha mejorado o ha empeorado. El salto fue sacar la decisión del modelo y meterla en código, porque lo determinista sí se puede probar en masa. Hoy cada cambio pasa por una batería de preguntas reales con su respuesta correcta ya anotada. Si hace fallar alguna que antes acertaba, no se publica.

Qué le pasa a un cambio antes de salir
Un cambio nuevo
Las preguntas de siempre
Las nuevas del cambio
¿Falla alguna?
Vuelve a revisión
Sale a producción
falla no falla
Las preguntas de siempre no se retiran cuando entra un cambio, se le suman las nuevas. Por eso una mejora en un sitio no puede estropear otro sin que nos enteremos antes de publicar, que es cuando todavía sale barato.

Lo que ve quien pregunta

Parte de lo que medimos se lo enseñamos al usuario y fue una decisión pensada. En uno de nuestros asistentes cada respuesta empieza diciendo qué periodo ha consultado, porque descubrimos que «el mes pasado» significaba cosas distintas según quién preguntara. Y si alguna fuente de datos no está disponible, el sistema responde con las que sí tiene y dice cuál se ha quedado fuera. Preferimos una respuesta que admite lo que le falta a una cifra incompleta con aspecto de completa.

Medir no evita que el sistema falle. Evita que falle en silencio.

Lo que no prometemos

No prometemos que el sistema acierte siempre. Prometemos enterarnos antes que tú y dejar escrito por qué falló, para que el mismo error no vuelva a pasar desapercibido.

Sin caja negra y sin ataduras

Los proveedores de IA cambian precios y retiran modelos. Algunas plataformas cierran sin más. El sistema que te entregamos está pensado para que ninguna de esas noticias llegue a ser un problema tuyo.

Cuéntanos tu reto
  • Repositorio a tu nombre Desde el primer día, no al final.
  • No compras una suscripción Compras un sistema que se queda en tu casa.
  • Traspaso de verdad Manual de operación y sesiones con tu gente si lo requieres.

La dependencia de un proveedor rara vez está en el contrato. Está en el día a día.

Dónde nace de verdad

Empieza cuando las instrucciones que gobiernan el sistema solo las conoce quien las escribió y nadie más puede comprobar si un cambio las empeora. Crece cuando la documentación cuenta lo que se pensaba hacer en lugar de lo que acabó haciéndose. Para cuando quieres cambiar de proveedor, ya nadie te lo impide por contrato, simplemente no queda nadie capaz de explicar cómo funciona aquello.

Y mientras tanto, el suelo se mueve

Los proveedores retiran modelos con regularidad y lo hacen por escrito. Anthropic publica su calendario de retiradas y avisa con sesenta días de antelación. El 15 de junio de 2026 dejaron de funcionar Claude Sonnet 4 y Opus 4, así que desde esa fecha cualquier llamada a esos identificadores falla. No es un accidente ni una mala práctica, es cómo funciona el sector. La pregunta es qué te cuesta a ti cada una de esas retiradas, porque cuando un proveedor retira un modelo, eso no debería afectarte.

Qué hay dentro del repositorio

Todo lo que define el comportamiento del sistema vive versionado en tu repositorio: las instrucciones del modelo con su historial de cambios, las pruebas con su respuesta correcta anotada, los manuales de operación y un catálogo de incidencias. Ese catálogo es el que más agradecen los equipos técnicos y el que casi nadie pide, porque no cuenta cómo se arregló cada problema, cuenta cómo se reconoce desde fuera, que es lo que sirve la próxima vez que el sistema se comporte raro.

Cambiar de modelo se prueba, no se promete

Que un modelo se pueda sustituir por otro es fácil de decir. Nosotros lo comprobamos antes de afirmarlo. Cuando valoramos cambiar el modelo de uno de nuestros sistemas por otro más barato, pasamos las dos versiones por el mismo juego de preguntas con su respuesta correcta anotada. El barato perdía diez puntos de acierto y en las preguntas donde había que elegir entre dos opciones parecidas caía del 89 % al 44 %, así que lo descartamos con esos números delante. Esa misma comprobación decide qué modelo entra en cada sitio, por eso nuestros sistemas en producción no corren todos sobre el mismo proveedor.

Ni producto cerrado ni suscripción

Un producto de catálogo decide por ti dónde viven tus datos, qué se puede integrar y cuándo sube el precio. Lo que te entregamos corre en la nube que te montemos, a tu nombre. La única salida al exterior son las llamadas al modelo, que tú apruebas una a una. Si tu comité decide que ni siquiera eso puede salir del perímetro, esa es una conversación que tenemos encima de la mesa desde el primer día, con lo que se gana y lo que cuesta.

Para quién escribimos la documentación

La documentación se escribe pensando en una persona concreta y no eres tú. Es quien mantenga esto dentro de dos años, alguien que hoy no está en ninguna reunión y que llegará sin contexto. Si lo que le dejamos escrito no viene acompañado de algo que pueda ejecutar para comprobarlo, no le sirve de nada. Nos aplicamos la misma regla que te aplicamos a ti.

Lo que no prometemos

No prometemos que nunca vayas a necesitarnos. Prometemos que el día que decidas prescindir de nosotros no tengas que pedirnos nada, porque lo tienes todo en tu casa desde el primer día.

Seguridad que no depende de que el modelo acierte

Dónde viven los datos y quién puede tocarlos son decisiones que tomamos al empezar, no al final. Es lo que acaba preguntando tu comité de seguridad y preferimos tener la respuesta antes que la reunión.

Cuéntanos tu reto
  • El modelo no escribe consultas Rellena un formulario cerrado y el código ejecuta.
  • Solo habla con lo que apruebes Contención por permisos, no por filtros.
  • RGPD Borrado real y plazos legales cumplidos.

El modelo decide, pero nunca es la autoridad.

Por qué un filtro no lo arregla

Un modelo de lenguaje recibe por el mismo canal las instrucciones que le damos y el texto que le llega de fuera, sin nada que separe unas de otro. Por eso alguien puede colar en ese texto algo que el modelo lea como una orden nueva y la cumpla sin saber que ha cambiado de bando. La seguridad de toda la vida resuelve esto separando datos de instrucciones. Aquí esa separación no existe, por eso la inyección de instrucciones encabeza por segunda edición consecutiva la lista de riesgos de OWASP para aplicaciones con modelos de lenguaje. En diciembre de 2025 el centro nacional de ciberseguridad británico fue más lejos y avisó de que probablemente no se arregle nunca como categoría, así que pidió dejar de esperar el parche para concentrarse en reducir el daño.

El montaje habitual deja la puerta abierta

Lo que hace peligroso a un asistente no es lo que sabe, es lo que puede hacer. En seguridad se habla de tres ingredientes inofensivos por separado y peligrosos juntos: acceso a datos privados, entrada de texto que viene de fuera y una vía libre para actuar sobre los sistemas. Los dos primeros son la razón de que el asistente exista, así que el que hay que cortar es el tercero. El montaje más extendido hoy hace justo lo contrario, porque enchufa el modelo a la base de datos con un conector que le deja escribir él mismo las consultas (los famosos MCP). Desde ese momento puede escribir cualquier consulta que el lenguaje permita. Lo único que se lo impide es una frase en su prompt, del tipo «no consultes la tabla de nóminas». Y esto no es una garantía, es una petición educada.

El modelo elige, el código ejecuta

Nuestro asistente de datos y la mayoría de los que construimos están montados al revés. El modelo no escribe la consulta. Rellena un formulario cerrado (un contrato JSON) con los campos que hemos definido nosotros y es un programa el que lee ese formulario y construye la consulta que llega a la base de datos. Ese programa solo sabe construir las consultas que le hemos enseñado, así que ninguna otra puede salir de ahí. En el asistente de planta que construimos para una empresa industrial pasa lo mismo con los documentos. El modelo elige una etiqueta de una lista cerrada y el código recupera el texto oficial asociado. Un mensaje malicioso puede, como mucho, equivocarse de opción dentro de una lista que ya hemos revisado.

El modelo interpreta, el código decide
Pregunta del usuario
Modelo
Validador
Bloqueo
Consulta parametrizada
Base de datos
contrato JSON rechaza acepta
El diagrama enseña una parada de consulta a datos, que es donde mejor se ve. El modelo nunca llega a tocar tus sistemas, interpreta la pregunta y entrega un contrato. A partir de ahí decide el código, que sí se comporta igual siempre. Es también el código quien decide qué puede ver cada persona. En este caso lo peor que puede conseguir un mensaje malicioso es que se elija mal dentro de una lista ya revisada. Cuando la parada es de lectura de documentos el modelo no elige de una lista, devuelve valores, así que ahí la defensa es la validación del paso siguiente y la confirmación de una persona en lo que mueve dinero.

Nunca más permisos que la persona

El asistente no tiene una credencial todopoderosa propia. Las consultas a los sistemas internos las lanza el usuario con sus permisos de siempre, los mismos que ya tiene en el resto de aplicaciones de la casa. Y ante la duda bloquea. Si la lista de permisos llega vacía, la respuesta es un no rotundo en lugar de un acceso por defecto.

Hay límites que no son técnicos

En uno de nuestros asistentes cualquiera con permisos consulta la producción de sus centros, pero el sistema no contesta sobre horas trabajadas de personas concretas, retrasos ni ausencias. Algunas de esas columnas están en la base de datos y sencillamente no se exponen. La restricción vive en el código, no en la esperanza de que el modelo se porte bien. La herramienta sirve para operar centros, no para hacer expedientes a nadie.

Datos de salud, el listón más alto

En Wazzy tratamos datos de salud, que el reglamento europeo coloca en la categoría más protegida que existe. Sí guardamos datos personales, porque sin ellos no hay servicio. Lo que cambia es cómo. El cifrado va campo a campo y el borrado respeta los cinco años que exige la conservación de la historia clínica, un plazo legal y no una preferencia nuestra. El listón nos lo marcan el reglamento europeo de inteligencia artificial y la ley de protección de datos.

Un atajo nuestro y cómo lo cerramos

En uno de nuestros sistemas existió una versión de pruebas que se saltaba el inicio de sesión. Se creó para ensayar cambios sin autenticarse cada vez, estaba documentada y estaba marcada para retirar, que es justo el tipo de cosa que sigue ahí dos años después. Lo que hicimos fue meter dentro del circuito autenticado un modo de ensayo que hace lo mismo, de forma que el atajo se quedó sin ninguna razón de ser. Desde entonces cada solución provisional que dejamos escrita lleva su fecha de caducidad.

La pregunta no es si alguien va a intentar engañar al modelo. Es qué puede llegar a hacer el modelo cuando lo consigan.

Lo que no prometemos

No prometemos un sistema invulnerable, porque eso no existe. Prometemos aplicar la máxima seguridad posible a las arquitecturas de IA que creamos y siempre tener bien atado todo lo que el modelo de lenguaje pueda hacer y no hacer.

Cómo trabajamos

Cuatro pasos para llevar la IA de la idea al uso diario.

  1. Explorar

    Mapeamos contigo dónde está el dolor y dónde la IA aporta. No empezamos con tecnología, empezamos con tu negocio.

    Lo que te llevas

    • Un mapa de dónde la IA aporta y dónde no
    • El estado real de los datos que haría falta usar
    • Las restricciones que hay que respetar desde el principio

  2. Priorizar

    De todos los casos posibles, escogemos los que tienen ROI tangible y son viables hoy. Si algo no compensa, te lo decimos.

    Lo que te llevas

    • Los casos ordenados por lo que aportan
    • Lo que descartamos, con el motivo escrito
    • Un primer caso acotado con el que empezar

  3. Implementar

    Construimos el sistema en producción, no un prototipo. Con las cuentas de tu organización, tus integraciones y tus reglas de seguridad.

    Lo que te llevas

    • El sistema funcionando sobre tu infraestructura
    • El repositorio a tu nombre desde el primer día
    • La batería de pruebas con su respuesta correcta anotada

  4. Optimizar

    Medimos su comportamiento semana a semana. Lo afinamos, ampliamos su alcance y absorbemos los nuevos modelos cuando salen.

    Lo que te llevas

    • Medición semanal con el resultado a la vista
    • El catálogo de incidencias, que dice cómo se reconoce cada fallo
    • Cada cambio pasa por las pruebas antes de llegar a tus usuarios
Empezar por el paso 1

Conectamos con tus sistemas

SharePoint, Confluence, Azure, SAP, ERP, CRM y los modelos de OpenAI, Anthropic y Google. Tus sistemas se quedan donde están y la IA pasa por ellos.

Cuéntanos tu reto

Blog

Lo que vamos descubriendo construyendo IA en producción con nuestros clientes.

Visitar blog

El juguete brillante

Cuatro capas entre tu empresa y la de al lado

Te cuento un secreto: no me gustan las arquitecturas agénticas

Antes que el prompt, los datos

El cero silencioso

Empezar un proyecto de IA es fácil. Mantenerlo vivo, casi imposible

La firma del síntoma vale más que el arreglo

El auditor que no se fía

Qué hace tu asistente cuando una herramienta se cae

Medir la IA por las ganancias, no por la productividad

Dos «no» que no son el mismo

El juguete brillante

El proyecto de IA que deslumbra en la demo y muere en el cajón tiene nombre y tiene antídoto. Un test de tres señales para distinguir la herramienta del capricho.

Leer más

FAQs

Las dudas que solemos resolver antes de empezar.

¿Mis datos salen de mi infraestructura?

Solo si tú decides. Desplegamos sobre tu nube o tus propios servidores, con las cuentas de tu organización y el sistema guarda lo mínimo para funcionar. La única salida son las llamadas al proveedor del modelo y tú apruebas cuáles se hacen y qué viaja en ellas.

¿De quién es el código que construís?

Tuyo. Te entregamos los repositorios, la documentación y la arquitectura desde el día uno. No hay caja negra ni dependencia tecnológica.

¿Cómo sabéis que la IA sigue funcionando bien después de entregarla?

De dos maneras. Una batería de pruebas se ejecuta antes de cada cambio y lo bloquea si baja la calidad. Y una vez en marcha, seguimos midiendo cada semana. Si el sistema deja de entender bien una pregunta, lo detectamos antes de que llegue al usuario final.

¿Trabajáis solo con grandes empresas?

No. Tenemos paquetes específicos para pymes (atención al cliente, cualificación de solicitudes, automatización documental) con la misma ingeniería que usamos en proyectos grandes.

Contacto

Cuéntanos tu reto.

Te respondemos en menos de 24 horas laborables. Sin presentación comercial de cuarenta diapositivas.

Cuéntanoslo como se lo contarías a un compañero. No hace falta que sepas qué tecnología lo resuelve.

Si ya tienes claro que quieres empezar, el formulario de exploración recoge lo que necesitamos para ponernos en marcha.