Construir o comprar IA: herramienta SaaS, API o desarrollo a medida

Hay 3 demos de proveedores agendadas para la semana que viene, el CEO quiere un plan de IA antes del consejo y alguien del equipo ya ha montado un prototipo con una clave de API durante el fin de semana. La pregunta sobre la mesa es construir o comprar. No es la pregunta por la que conviene empezar.

Hay 3 opciones, no 2. Puede comprar una herramienta SaaS, llamar a un modelo por API e integrarlo en su propio producto, o construir algo a medida en torno a sus datos y sus procesos.

Compre una herramienta SaaS cuando la tarea es genérica e interna. Integre una API cuando la funcionalidad vive en su producto pero la inteligencia es genérica. Construya a medida cuando se cumplen dos o más de estas condiciones: la IA es lo que le diferencia, funciona con sus propios datos, opera a gran volumen o entra a fondo en sus sistemas.

Así es como distinguimos los tres casos, empezando por el paso que la mayoría de los equipos se salta.

Primero, ponga el trabajo por escrito

Antes de comparar nada, escriba un párrafo: quién lo usa, qué entra, qué sale, cuántas veces al día y qué pasa cuando la respuesta es incorrecta. Lleva una hora. Ahorra semanas de demos.

Ese párrafo suele responder por sí solo a la mitad de la pregunta. «Nuestro equipo comercial quiere resúmenes de reuniones en el CRM» es un problema distinto de «nuestros clientes hacen 2.000 preguntas al día sobre sus contratos». El primero probablemente es una suscripción; el segundo probablemente no.

La última parte es la que más pesa. Si una respuesta incorrecta le cuesta 10 segundos a un compañero, puede comprar casi cualquier cosa. Si le cuesta un cliente, un contrato o un problema de cumplimiento normativo, necesita controlar cómo se produce la respuesta.

Cuándo basta una herramienta SaaS

Compre cuando la tarea es igual en su empresa que en cualquier otra. Actas de reuniones, transcripción, ayuda a la redacción, primera clasificación de tickets, búsqueda en una unidad compartida. Los proveedores ya las han construido, y un equipo entero mejora esa única funcionalidad cada mes.

Señales de que una herramienta SaaS es la decisión correcta:

• los usuarios son sus propios equipos, no sus clientes
• la herramienta funciona con el software que ya paga
• nadie lo notaría si cambiara de proveedor el año que viene
• los datos que toca pueden salir de sus sistemas según las condiciones del proveedor

Antes de firmar, pida al proveedor que pruebe la herramienta con 50 de sus documentos reales, no con su set de demo. La diferencia entre ambos es el trabajo que acabará haciendo en hojas de cálculo 6 meses después.

El coste es una suscripción por usuario y una tarde de configuración. El coste oculto es la dependencia en los flujos de trabajo, no en los datos: compruebe cómo recupera su historial antes de desplegarla a 200 personas.

Cuándo basta una integración por API

Integre cuando la funcionalidad pertenece a su producto o a sus herramientas internas, pero la inteligencia en sí es genérica. Resumir un documento, extraer campos de una factura, clasificar un correo, redactar una respuesta que revisa una persona. La API de un proveedor de modelos hace la parte difícil; su código hace el resto.

Ese «resto» es la mayor parte del trabajo, y es donde los equipos subestiman el esfuerzo. La llamada al modelo son unas pocas líneas. Alrededor necesita:

• el contexto adecuado en cada petición, extraído de sus propios sistemas
• una forma de comprobar la respuesta antes de que llegue a un usuario
• registros, para ver qué se pidió y qué se devolvió
• un techo de gasto, porque el precio por uso crece con su tráfico
• un plan B cuando el proveedor va lento o está caído

Lo que tarda una integración así depende de lo profundo que entre en sus sistemas. Una primera versión totalmente a medida lleva más tiempo: en nuestros proyectos, normalmente entre 3 y 6 semanas desde el arranque.

Compruebe dos cosas antes de comprometerse. Primero, adónde van los datos: algunos proveedores procesan las peticiones en Estados Unidos por defecto, y varios ofrecen ya alojamiento en Europa o despliegue en su propia cuenta cloud. Segundo, cómo cambiará de modelo más adelante: mantenga al proveedor detrás de una sola capa de su código, para que cambiarlo sea un cambio de configuración y no una reescritura.

Cuándo compensa el desarrollo a medida

A medida no significa entrenar su propio modelo. Para la mayoría de las empresas, significa un sistema construido alrededor de modelos existentes: sus flujos de datos, su búsqueda documental, su evaluación, su interfaz, sus reglas. Compensa cuando se cumplen 2 de estas 4 condiciones. Una sola es un motivo para mirar más de cerca, no para construir.

Es lo que le diferencia. Si la funcionalidad es la razón por la que los clientes le eligen frente a un competidor, alquilarla al mismo proveedor que usa su competidor regala la ventaja. Usted quiere controlar el comportamiento, la hoja de ruta y la velocidad a la que mejora.

El valor está en sus datos. Cuando la respuesta depende de años de documentos internos, datos de producto o historial de clientes, el trabajo está en preparar esos datos, mantenerlos al día y controlar quién ve qué. Ninguna herramienta estándar conoce su modelo de permisos.

El volumen cambia las cuentas. Con poco volumen, el precio por usuario o por llamada es barato. Con mucho volumen, la factura mensual puede superar el coste de construir y operar su propio sistema. Haga los números con el volumen del año que viene, no con el de este mes.

La integración es profunda. Una funcionalidad que lee de 3 sistemas internos, escribe en 2 y tiene que respetar reglas de negocio en cada paso no es un plugin. Es software, y hay que construirlo y mantenerlo como el resto de su producto.

Una primera versión a medida cuesta más al principio que una integración, y después suma un coste mensual de operación. Ese coste de operación es el que olvidan la mayoría de los presupuestos.

Alguien tiene que operarlo: vigilar las respuestas, actualizar prompts y datos, seguir las nuevas versiones de los modelos, corregir lo que se desvía. Inclúyalo en el presupuesto desde el primer día, y haga una pregunta a cualquier socio antes de firmar: ¿quién lo opera en el tercer mes? La mayoría de los presupuestos terminan en el lanzamiento.

Nuestra respuesta es el mismo equipo, que se queda para la supervisión, las mejoras y la siguiente iteración, o un traspaso ordenado al suyo.

Construir o comprar IA: la tabla de decisión

Lea la tabla por filas. La línea que decide suele ser «Riesgo principal», no el coste.

La mayoría de las empresas acaban con las tres, para trabajos distintos. El error es elegir una sola respuesta para toda la empresa, normalmente la que al equipo le resultaba más interesante construir.

Un orden sensato: comprar para la productividad interna, integrar donde una funcionalidad tiene que vivir en su producto y reservar el desarrollo a medida para los uno o dos sitios donde cambia sus números. Empiece por la versión más pequeña que llegue a producción, mídala y decida después si merece más.

Una opinión externa antes de firmar

Esta es la pregunta que trabajamos en una auditoría gratuita. Traiga el párrafo de la primera sección: en una hora repasamos su negocio, y después recibe un documento breve por escrito que dice qué comprar, qué integrar, qué construir y qué le desaconsejamos. Reserve una auditoría gratuita antes de firmar con un proveedor o de asignar un equipo a un proyecto.