integrar inteligencia artificial en tu empresa: lo que nadie te dice antes de cotizar.

si estás evaluando integrar inteligencia artificial a tu empresa, probablemente ya recibiste una cotización. y probablemente nadie te explicó qué pasa con tu operación el día que la ia falle. este artículo es eso: lo que deberías exigir antes de pagar — escrito por alguien que construye estos sistemas, no por alguien que los vende con slides.

contexto primero: el mercado de 'ia para empresas' en chile se llenó rápido. hay agencias que revenden chatbots genéricos, consultoras que cobran por hora para 'explorar casos de uso', y muy pocos equipos que han puesto sistemas con ia en producción y los han mantenido funcionando. desde afuera, las tres cosas se cotizan parecido. desde adentro, son productos completamente distintos. la diferencia se detecta haciendo las preguntas correctas — y para eso está esta guía.

// el riesgo que nadie pone en la propuesta

tu negocio ya funciona. tienes un sistema que factura, una operación que despacha, clientes que pagan. ese es tu activo más valioso, y es exactamente lo que una mala integración de ia pone en riesgo. el error estructural más común es conectar el modelo de ia directamente adentro del sistema que sostiene el negocio. cuando eso pasa, heredas tres problemas que no aparecen en la propuesta comercial:

• -continuidad: los modelos de ia dependen de servicios externos que fallan, cambian de versión y responden con latencias impredecibles. si tu sistema de ventas depende de que esa api responda, tu sistema de ventas hereda cada una de esas fallas.
• -costo variable: las apis de modelos se cobran en dólares y por uso. si nadie diseña el control de contexto — cuánta información se le envía al modelo en cada llamada — la cuenta mensual crece junto con tu operación, y la conoces recién cuando llega.
• -dependencia: si el sistema queda amarrado a un solo proveedor de modelos, cualquier cambio de precios o de condiciones de ese proveedor se convierte en tu problema, sin salida práctica.

// cómo se ve una integración bien hecha

se resume en una frase que puedes usar como filtro en cualquier reunión comercial:

"la ia corre al lado de tu sistema, no adentro de él."

en la práctica: tu sistema principal — el que factura, despacha y atiende — sigue operando exactamente igual que hoy. la ia vive en una capa separada que recibe tareas, las procesa de forma asíncrona y devuelve resultados cuando están listos. si el modelo falla, se demora o entrega algo inservible, esa tarea queda en cola o se descarta. tu operación ni se entera. esto no es un detalle técnico: es la diferencia entre 'la ia mejoró mi negocio' y 'la ia botó mi sistema un viernes en la tarde'.

nota técnica: así lo construimos nosotros

el patrón se llama arquitectura orientada a eventos. la idea completa cabe en unas pocas líneas:

// la ia corre al lado, no adentro

// 1. tu sistema emite un evento — y sigue operando
await publishEvent('agent.task', payload);

// 2. el agente procesa en su propia infraestructura, asíncrono
// 3. el resultado vuelve cuando está listo (webhook / websocket)

// si la ia falla, el evento espera en cola.
// tu operación no espera a nadie.

no necesitas entender el código. necesitas que tu proveedor sí lo entienda — y que pueda explicarte, en tu idioma, por qué eligió ese patrón y no otro.

// las 5 preguntas que debes hacer antes de firmar

estas preguntas separan a quien construye sistemas de quien revende una api con interfaz bonita. llévalas escritas a la reunión.

1. ¿qué pasa con mi operación si el modelo de ia se cae?

respuesta aceptable: 'nada — tu sistema principal sigue operando, las tareas de ia quedan en cola y se procesan cuando el servicio vuelve'. señal de alerta: cualquier versión de 'eso casi nunca pasa'. los servicios externos fallan; la pregunta nunca es si van a fallar, sino qué pasa con tu negocio ese día.

2. ¿cómo audito lo que decidió el agente?

si un agente de ia respondió a un cliente, clasificó una solicitud o priorizó un pedido, necesitas poder reconstruir qué decidió, cuándo y con qué información. respuesta aceptable: cada decisión queda registrada en una base de datos consultable — qué entró, qué salió, en qué momento. señal de alerta: 'el modelo es una caja negra, pero funciona bien'. sin registro de decisiones no hay control de calidad, y sin control de calidad estás delegando tu reputación a un sistema que nadie supervisa.

3. ¿qué pasa con mis datos?

tres sub-preguntas concretas: ¿qué datos de mi empresa y de mis clientes se envían al modelo? ¿el proveedor del modelo puede usarlos para entrenar? ¿dónde quedan almacenados? respuesta aceptable: un mapa claro de qué dato viaja a dónde, condiciones de api con cláusula de no-entrenamiento, y la opción de excluir información sensible del flujo. señal de alerta: un proveedor que no distingue entre usar un modelo y entregarle tus datos al dueño del modelo.

4. ¿cuánto me va a costar por mes después de la entrega?

un proyecto de ia tiene dos precios: el desarrollo, que se paga una vez, y el consumo de api, que se paga todos los meses, en dólares, proporcional al uso. respuesta aceptable: una estimación de consumo mensual con supuestos explícitos, más un diseño de control de contexto que mantenga ese consumo acotado a medida que creces. señal de alerta: una propuesta que solo muestra el precio de desarrollo. el costo recurrente no es letra chica — es el número que decide si el proyecto se paga solo o se convierte en un gasto fijo que nadie defendió.

5. ¿qué pasa si mañana quiero cambiar de modelo o de proveedor?

los modelos mejoran y bajan de precio cada pocos meses. un sistema bien construido trata al modelo como una pieza reemplazable: hoy usa uno, mañana otro, sin reescribir nada importante. respuesta aceptable: 'el modelo está detrás de una capa de abstracción; cambiarlo es configuración, no un proyecto nuevo'. señal de alerta: el nombre de un proveedor específico cableado en cada sección de la propuesta.

// cuánto cuesta esto en chile

hablemos de plata, porque es la pregunta real detrás de todo lo anterior. en mi lista de precios los proyectos parten en $1.000.000 clp, y los sistemas con ia integrada parten en $8.5 millones clp. la distancia entre esos dos números es exactamente lo que describe este artículo: la ingeniería que aísla tu operación del comportamiento del modelo, el registro auditable de decisiones, el control del costo de api y la independencia de proveedor. eso es lo que estás comprando. la llamada a la api la puede hacer cualquiera.

si te cotizan 'integrar ia' por una fracción de eso, casi siempre es una de dos cosas: un chatbot genérico montado por encima de tu sistema, que no toca tu operación real, o un proyecto que va a aprender estas lecciones usando tu negocio como laboratorio. ninguna de las dos es una inversión — la primera es decoración y la segunda es riesgo con factura.

// la evidencia que sí puedes exigir

a cualquier proveedor — incluido yo — exígele trabajo verificable, no promesas. lo mío está a la vista: veintidosbg.cl y vortice360.cl son sitios en producción que construí y que puedes visitar hoy. en investigación, publiqué un paper en arxiv (arXiv:2606.05594) con doi permanente (10.5281/zenodo.20501960). y además de proyectos para clientes, opero sistemas multi-agente propios en producción — mi propio laboratorio, donde cada patrón se prueba antes de llegar a un cliente. el detalle está en /proyectos.

la decisión de integrar ia no es técnica: es comercial. estás decidiendo cuánto riesgo operacional aceptas a cambio de cuánta eficiencia. las cinco preguntas de arriba son tu seguro — úsalas con cualquier proveedor, no solo conmigo. si las respuestas no llegan claras, la cotización no está lista para firmarse.