Insights
Página 2 de 6
Automatizar siniestros con IA: qué entra en vigor el 2 de agosto y qué se aplazó a 2027
El Reglamento (UE) 2026/1744 se publicó en el DOUE el 24 de julio de 2026 y está en vigor desde el 27: las obligaciones de los sistemas de alto riesgo del Anexo III se aplazan al 2 de diciembre de 2027 y las del Anexo I al 2 de agosto de 2028. Pero la transparencia del artículo 50 no se aplazó y entra el 2 de agosto de 2026 —con marcado de contenido sintético exigible desde diciembre para los sistemas generativos que ya estaban en el mercado—, así que si un asistente abre el parte o redacta la comunicación al asegurado, eso te afecta ya. Esta pieza desglosa las seis fases de un siniestro y dónde encaja la IA sin arriesgar, la delimitación del Anexo III 5(c) (tarificación en vida y salud, no la tramitación; No Vida fuera), los tres motivos por los que los pilotos de siniestros no llegan a producción —condicionado inaccesible, cero trazabilidad, humano en el sitio equivocado— y un camino de siete pasos para empezar por una tipología acotada con el contexto ordenado.
Cómo redactar la memoria técnica de una licitación
Redactar la memoria técnica de una licitación no es describir tu empresa: es responder, punto por punto, a un pliego que ya te ha dicho cómo te va a puntuar. Este artículo recorre el método —leer el pliego al revés, empezando por los criterios de valoración, y construir el índice alrededor de ellos con extensión proporcional a los puntos—, el error que descalifica sin remedio (mezclar información económica o valorable por fórmula en el sobre técnico), y la regla de respaldo: si una afirmación no puede apuntar a un documento de tu empresa que la sostenga, o se convierte en algo que sí puede, o se cae. Y después el problema estructural que ningún consejo de redacción resuelve: una empresa que licita con regularidad ya ha escrito casi todo lo que necesita, pero vive disperso, así que cada licitación empieza cerca de cero y la decisión real acaba siendo a cuál de las tres presentarse. Con el coste invisible de externalizar (el conocimiento se va con el tercero) y dónde encaja la IA y dónde no: acelera localizar, seleccionar y adaptar material propio citando la fuente; no gana la licitación, no sustituye la revisión humana y no inventa lo que no tienes.
Shadow AI: la IA que tus equipos ya usan sin control (y cómo gobernarla)
El shadow AI es el uso de herramientas de IA dentro de tu empresa sin la aprobación ni el control de tecnología: el sucesor del "shadow IT", con el agravante de que la IA se traga datos. Cuando haces el inventario en una empresa mediana, el número sorprende: decenas de herramientas en uso hoy —ChatGPT individual, copilots sin política, IA en el CRM o el correo— sin auditoría. Este artículo desglosa qué es y por qué casi todas las empresas lo tienen, el riesgo real que no ves en ningún presupuesto (fuga de datos, cumplimiento/AI Act, inconsistencia, coste invisible, decisiones sin rastro), por qué prohibirlo no funciona (se vuelve más oculto y apagas una señal de demanda real), y cómo gobernarlo sin matarlo: inventario sin caza de brujas, una política clara y usable, y —la clave— un entorno corporativo de IA gobernada que sea mejor que el atajo individual, para que el shadow desaparezca solo. Buyer CIO/CISO/COO, ángulo gobernanza.
Automatizar el customer support B2B con IA, sin alucinar a tus cuentas
Automatizar el customer support B2B con IA es de las apuestas de mayor retorno: gran parte de los tickets son variaciones de las mismas preguntas. Pero el soporte B2B tiene una diferencia crítica frente al de consumo: cada cliente es una cuenta con un contrato, y una respuesta inventada o genérica es una grieta en una relación cara de ganar. Este artículo desglosa por qué el soporte es el candidato perfecto para la IA y por qué duele hoy, por qué un chatbot genérico es peligroso en B2B (alucina respuestas sobre tu producto, no conoce el contexto de la cuenta, escala mal a la persona, no deja rastro) y qué exige una automatización que puedas poner delante del cliente: ingeniería de contexto de tu producto y políticas, verificación con límites (que diga "no lo sé" y escale en vez de inventar), escalado humano limpio con contexto, y trazabilidad. Empezando por deflexión asistida y midiendo deflexión, tiempo de resolución y CSAT.
AWS Bedrock vs Azure OpenAI para mid-market: cuál elegir
Si comparas AWS Bedrock y Azure OpenAI para tu empresa, esta guía da una lectura honesta de las dos —para qué encaja cada una por los ejes que importan en mid-market: catálogo de modelos, portabilidad, encaje con tu cloud, gobernanza y residencia de datos, coste— y después ataca el error caro: creer que la decisión de plataforma determina el resultado. Elegir plataforma es, de facto, elegir a qué nube te casas para años, y lo que más pesa en el coste no es la tarifa de hoy sino el coste de salida. La respuesta no es "Bedrock o Azure", es arquitectura: elige por encaje real pero diseña multi-modelo desde el día uno, mantén tu contexto de negocio fuera del vendor y mide el coste por tarea útil. Con aviso de sesgo declarado (onext construye Enterprise AI sobre Bedrock por su acceso multi-modelo) y tesis de portabilidad / sin lock-in.
Agente de IA en tu producto SaaS: ¿construir el equipo o traer un partner?
Meter un agente de IA en tu producto es la feature que todo Head of Product tiene en el roadmap de 2026: un copiloto, un agente que ejecuta un flujo. La parte fácil es enseñar que funciona; la difícil —y la que cuesta dinero de verdad— es decidir cómo lo construyes y sostienes. Este artículo ordena la decisión: qué es un agente en tu producto (y por qué no es un chatbot), por qué el demo engaña (el 80% invisible: fiabilidad con casuística real, evaluación, coste por tarea, seguridad, mantenimiento), y la decisión de 50-300k€ entre construir el equipo in-house (control máximo pero caro, lento y difícil de retener), comprar una solución cerrada (rápida pero sin diferenciación) o traer un partner que construye y transfiere (velocidad de comprar con la propiedad de construir). La regla: lo que te diferencia constrúyelo (con partner si no tienes el equipo); lo que es infraestructura, cómpralo. Track E, ticket alto, buyer Head of Product / CTO de producto.
Automatizar cuentas por pagar con IA, sin errores contables
Automatizar cuentas por pagar con IA es de las apuestas de retorno más claro para un CFO: alto volumen, muy manual y repetitivo (capturar la factura, casarla con el pedido y la recepción, codificarla, aprobarla, contabilizarla). También es donde el error tiene consecuencia directa: un importe mal leído se paga de más, una cuenta mal asignada descuadra el cierre, un duplicado no detectado es dinero que sale dos veces. Este artículo desglosa por qué es un candidato ideal a automatizar, por qué la IA genérica falla en finanzas (extrae mal importes, codifica a la cuenta equivocada, no detecta duplicados, no deja rastro auditable), y qué exige una automatización gobernada: contexto de tu plan de cuentas, maestro de proveedores y reglas de aprobación; verificación de importes y three-way match; detección de duplicados y anomalías; trazabilidad para auditoría; integración con tu ERP y humano en las excepciones. El proceso financiero del clúster de automatización documental de onext Enterprise AI.
Responder RFPs con IA: de semanas por propuesta a respuesta gobernada
Automatizar la respuesta a RFP con IA es tentador: responder una petición de propuesta es caro, lento y repetitivo, y buena parte ya la escribiste en propuestas anteriores. Pero es el proceso donde peor sienta hacerlo a ojo: en una oferta un error se negocia; en una RFP, un requisito que se te escapa te deja fuera antes de que nadie lea tu propuesta. Este artículo desglosa por qué responder RFPs es tan caro (matrices de requisitos, plazos, corpus de respuestas previas, equipos multidisciplinares), por qué la IA genérica es más peligrosa aquí que en una oferta (se salta requisitos → descarte; alucina cumplimientos y certificaciones → riesgo legal; cita specs que no son; responde en genérico y puntúa bajo), y qué exige una automatización gobernada: contexto de tus propuestas ganadas, verificación de cobertura requisito a requisito, trazabilidad de cada afirmación y el equipo de bid en control. La otra cara del proceso documental que onext automatiza en Enterprise AI.
Automatizar tus ofertas comerciales con IA, de forma gobernada
Automatizar la generación de ofertas comerciales con IA es una de las oportunidades de mayor retorno inmediato en una empresa mediana: es repetitivo, intensivo en documentos y consume horas de tu mejor gente. También es de los que peor salen sin método. El experimento típico —pedirle a un chatbot que redacte la propuesta— impresiona en la demo y falla en producción porque la IA no conoce tu negocio: inventa precios, ignora tus descuentos, aplica condiciones que no corresponden. Y en una oferta, un precio mal es dinero o un problema legal. Este artículo desglosa por qué las ofertas son el proceso perfecto para automatizar, por qué el primer intento con ChatGPT no llega a producción, y qué exige una automatización gobernada: ingeniería de contexto (catálogo, reglas de precio, plantillas), verificación humana en lo que toca precio, trazabilidad para finanzas y legal, integración con CRM/ERP y coste por oferta medido. Con la generación de ofertas como uno de los procesos que onext automatiza dentro de Enterprise AI.
Claude vs Cursor vs Copilot para empresas: cuál elegir
Tu equipo pide (o ya usa) Claude, Cursor o GitHub Copilot, y toca decidir en cuál estandarizar y cuánto presupuestar. Esta guía da una lectura honesta de las tres —para qué brilla cada una y en qué situación encaja, por los ejes que le importan a un CTO (integración, gobernanza enterprise, trabajo agéntico, modelo de coste, curva de adopción)— y después ataca el error caro: creer que la decisión de herramienta determina el retorno. No lo es. La misma licencia produce ×3 o ×0 según cómo se trabaje. El 80% que decide el ROI es el método —especificación (SDD), ingeniería de contexto y verificación humana— con el que tu equipo convierte cualquiera de las tres en throughput medible. Con aviso de sesgo declarado (onext trabaja sobre Claude) y tesis agnóstica.
IA para healthtech: la IA de tu producto de salud, a producción
Personalizar el plan de cada usuario, un asistente que responda dudas, contenido adaptado: la IA promete mucho en un producto de salud o bienestar, y la demo sale bien en una tarde. Lo difícil llega después: que funcione con miles de usuarios reales, sobre datos personales de salud, sin un equipo de IA en plantilla. Ese salto es donde casi todos los productos de salud se atascan, y no es por el modelo. Este artículo desglosa por qué la IA de un producto de salud se queda en la demo (personalización genérica, datos sensibles y regulados, sin equipo IA in-house), qué exige de verdad producción (ingeniería de contexto, verificación y límites de seguridad, privacidad desde el diseño, coste por interacción útil) y cómo darlo por casos de uso concretos con un partner que construye el producto end-to-end. Con el caso Hacktua como prueba —y una nota honesta: bienestar B2C, no sistema clínico.
IA para aseguradoras: por qué los pilotos no llegan a producción
Las aseguradoras mid-market se llenan de pilotos de IA que impresionan en la demo y se atascan antes de producción. Un proveedor enseña que la IA lee un parte de siniestro o clasifica un riesgo de suscripción en segundos; seis meses después, sigue siendo un piloto. No es un problema de modelo: es de contexto (la IA no conoce tus ramos, reglas ni condicionados), de criterio de calidad reproducible (sin evals, cada release es una apuesta sobre primas y pagos) y de trazabilidad y coste (sin registro de decisiones ni coste por expediente, cumplimiento bloquea el despliegue y el caso de negocio se diluye). Este artículo desglosa los tres procesos donde más promete y más se atasca la IA aseguradora —siniestros, suscripción, respuesta documental/RFP—, qué exige de verdad producción en un sector regulado (contexto, verificación, AI Act, coste medido) y cómo empezar por un proceso concreto en vez de un gran proyecto que lo promete todo.
Cómo medir si la IA de tu producto funciona: evals y coste
"Parece que funciona" no es una métrica: es una impresión, y con IA generativa las impresiones engañan. Para llevar una feature de IA de tu producto SaaS a producción y mantenerla rentable necesitas medir dos cosas, y solo dos: la calidad verificada (evals reproducibles que te dicen si la salida es correcta, no si suena bien) y el coste por tarea útil (créditos consumidos entre outputs que pasaron la eval y se usaron de verdad). Este artículo es la guía práctica: cómo montar evals que sí sirven por niveles, cómo calcular el coste por tarea útil con un ejemplo numérico, qué tablero mínimo mirar cada semana, cuándo una feature de IA merece seguir viva, y los errores que revientan la medición. Sin esto, cada release es una apuesta y cada factura una sorpresa.
Integrar IA en tu producto SaaS sin hipotecar el roadmap
Meter IA en tu producto SaaS —RAG, agentes, features con LLM— es fácil de empezar y difícil de terminar: funciona en la demo y se rompe con la casuística real, porque no conoce tu producto ni tiene criterio de calidad reproducible, y el coste se dispara sin que nadie sepa cuánto costará mantenerlo. El problema no es el modelo: es que producción exige consistencia, gobierno y escala, y eso solo lo da la ingeniería de contexto (recoger cómo funciona tu producto y convertirlo en el contexto que usa la IA) con verificación humana en cada paso y el coste por tarea útil medido desde el día uno. Cómo hacerlo sin hipotecar el roadmap: qué construir primero, cómo medir si funciona, y cuándo build vs. buy.
Ingeniería de contexto vs. prompt engineering
Si tu equipo lleva meses afinando prompts para ChatGPT, Claude o Copilot, consigue demos brillantes y aun así nada llega a producción de forma fiable, no es la herramienta ni el modelo: es que hay dos disciplinas distintas detrás de "trabajar con IA" y confundirlas te deja atascado en la que tiene techo. El prompt engineering afina la instrucción de una interacción: no acumula, vive en la cabeza de quien lo escribe y depende del modelo de turno. La ingeniería de contexto construye lo que el modelo sabe de tu negocio —reglas, criterios, dominio— como un activo reutilizable, tuyo, que sobrevive al cambio de modelo. El prompt es cómo preguntas; el contexto es lo que el modelo sabe de ti cuando preguntas. Por qué esa distinción decide si la IA llega a producción.