Qué documentos exigirle a un proveedor de IA antes de firmar

El error de firmar por portafolio, no por papel

Cuando una empresa decide contratar un proveedor de inteligencia artificial, el proceso de evaluación casi siempre se reduce a tres preguntas: ¿qué han hecho antes?, ¿cuánto cuesta? y ¿en cuánto tiempo lo entregan? El área de compras revisa el portafolio, alguien en dirección reconoce un logo conocido entre los “casos de éxito” y con eso basta para avanzar. El error no es preguntar por experiencia. El error es detenerse ahí.

Un portafolio con logos no prueba nada. No dice si el proveedor implementó el sistema completo o solo hizo una demo para ese cliente. No dice si el contrato de ese caso terminó bien o si la relación se rompió a mitad de camino. No dice, sobre todo, quién quedó siendo dueño de lo que se construyó. Esa información no está en una lámina de presentación: está en documentos concretos que el proveedor debe entregar antes de que la empresa firme una sola línea.

Lo que se repite, contrato tras contrato, es una empresa que pide referencias por cortesía, nunca las llama, y firma un contrato de servicios genérico que el mismo abogado usa para contratar limpieza de oficinas. Nadie exige un acuerdo de propiedad sobre el código y los datos. Nadie pide un plan de cómo se va a medir el resultado. Nadie pregunta qué pasa si el proveedor cambia de dueño o simplemente deja de responder correos en el mes ocho.

El costo de ese descuido no aparece el día de la firma. Aparece meses después, cuando la empresa quiere cambiar de proveedor y descubre que el sistema no se puede migrar, que los datos de ajuste no le pertenecen o que nadie puede demostrar si el proyecto generó el resultado por el que se pagó. Los documentos que se piden antes de firmar no son burocracia: son el único mecanismo real de protección que le queda a la empresa una vez que el dinero ya se movió.

Qué es (y qué no) exigir documentos antes de firmar

Exigir estos documentos no es desconfiar del proveedor por principio. Es aplicar el mismo criterio que se aplicaría a cualquier proveedor que va a tocar un activo crítico del negocio: los datos, los procesos y, cada vez más, la propiedad intelectual que resulta de automatizar una parte del trabajo.

• No es un ritual legal para “cubrirse las espaldas” sin leer lo que dice cada documento.
• No es copiar una checklist genérica de contratos de software y aplicarla igual a un proveedor de IA.
• No es responsabilidad exclusiva del área legal: compras, TI y el dueño del proceso de negocio deben leer estos documentos, no solo firmarlos.
• No es un obstáculo para avanzar rápido: un proveedor serio ya tiene la mayoría de estos documentos listos y los entrega sin fricción.
• No es exclusivo de proyectos grandes: incluso un piloto de bajo costo puede dejar a la empresa atrapada si no define de quién son los datos y el sistema.

Los documentos que prueban que el proveedor es quien dice ser

El primer bloque de documentos no habla de tecnología. Habla de si el proveedor existe de verdad como la empresa que dice ser y si tiene la capacidad real para hacer lo que promete. Esto se prueba con papel, no con una llamada de referencia improvisada.

Casos con contexto, no logos

Pedir “casos de éxito” sin más produce una lámina con logos. Pedir un caso con contexto produce información verificable: el sector del cliente anterior, el problema de negocio que resolvió, el alcance real de lo que se implementó y un contacto directo (nombre y cargo, no un correo genérico de marketing) que la empresa pueda llamar. La ausencia de esto revela algo específico: que el “caso de éxito” fue una demo, un piloto que nunca llegó a producción, o un proyecto de otra industria que no tiene nada que ver con esta empresa.

• Nombre y cargo de un contacto real del cliente anterior, no un correo genérico de marketing.
• Descripción del alcance implementado, no del alcance vendido: qué quedó funcionando en producción, no en la propuesta.
• El resultado medido, con la métrica que se usó y quién la validó del lado del cliente, no del proveedor.
• La duración real de la relación: si el proyecto “fue un éxito” pero el contrato terminó a los cuatro meses, esa es la pregunta que hay que hacer.

Papeles legales y administrativos mínimos

Antes de firmar, la empresa necesita confirmar que quien va a firmar del otro lado tiene la capacidad legal para hacerlo y que la entidad detrás del proveedor existe formalmente. No es desconfianza: es la misma diligencia que se aplicaría a cualquier proveedor que va a manejar información sensible del negocio.

• Constitución de la empresa y vigencia de poder de quien firma el contrato: sin esto, el contrato puede quedar sin efecto si la persona que firmó no tenía la facultad.
• Situación tributaria al día (RUC activo, sin inhabilitaciones): un proveedor con problemas fiscales serios es un proveedor con riesgo de desaparecer a mitad de proyecto.
• Póliza de responsabilidad civil o de errores y omisiones, cuando el proyecto toca datos sensibles o procesos críticos: define quién responde si algo falla.
• Referencias comerciales o bancarias, en proyectos de monto alto: confirman que el proveedor tiene la solidez financiera para sostener el proyecto hasta el final.

Los documentos que protegen a tu empresa

El segundo bloque es el que más se salta y el que más caro sale saltarse. Estos documentos no describen lo que el proveedor va a construir: describen qué le pertenece a la empresa una vez que el proyecto termine y qué puede hacer el proveedor con la información que tocó durante el trabajo.

El acuerdo de propiedad sobre datos y código

Este es el documento que define, en blanco y negro, quién es dueño del código, los modelos ajustados, los prompts, las integraciones y los flujos de trabajo que resultan del proyecto. Sin este acuerdo, la posición por defecto en muchos contratos de servicios favorece al proveedor: la empresa paga por un “servicio”, no por un “activo”, y el proveedor conserva derechos sobre lo construido. La ausencia de este documento es la señal más clara de que el proveedor está diseñando la relación para que la empresa dependa de él de forma indefinida.

• Propiedad explícita del código fuente y no solo de una licencia de uso sobre una plataforma cerrada del proveedor.
• Propiedad de los datos de ajuste que la empresa entregó, incluyendo cualquier derivado que el proveedor haya generado con ellos.
• Derecho de exportación y portabilidad: la empresa debe poder llevarse el sistema, los datos y la configuración si decide cambiar de proveedor.
• Cláusula de no uso de los datos de la empresa para entrenar productos o servicios que el proveedor vende a otros clientes, salvo autorización expresa.

El plan de tratamiento y borrado de datos

Todo proyecto de IA implica mover datos de la empresa hacia el proveedor: registros de clientes, historiales de ventas, conversaciones, documentos internos. El plan de tratamiento de datos responde tres preguntas que casi nunca se hacen antes de firmar: dónde se van a almacenar esos datos, quién dentro del proveedor va a tener acceso a ellos y qué pasa con esos datos cuando el contrato termina.

• Ubicación y forma de almacenamiento de los datos durante el proyecto (infraestructura propia del proveedor, de un tercero en la nube, o de la empresa).
• Lista de roles con acceso a los datos, no solo “el equipo del proyecto” como frase genérica.
• Plazo y método de borrado de los datos al terminar el contrato, con evidencia de que el borrado ocurrió.
• Protocolo ante un incidente de seguridad que involucre los datos de la empresa durante el proyecto.

El acuerdo de confidencialidad y los requisitos de seguridad

El acuerdo de confidencialidad protege la información que se comparte durante la evaluación y ejecución del proyecto: procesos internos, cifras de negocio, decisiones estratégicas que se discuten al diseñar el sistema. Los requisitos de seguridad, en cambio, obligan al proveedor a demostrar cómo protege esa información mientras la tiene: cifrado, control de acceso, separación de ambientes de otros clientes. Un proveedor que no puede mostrar esto en un documento concreto, y solo lo promete de palabra, no está listo para tocar datos sensibles del negocio.

Los documentos que definen el trabajo

El tercer bloque no protege a la empresa de un riesgo legal: protege al proyecto de la ambigüedad, que es la causa más común de que una implementación de IA se alargue, se encarezca o simplemente no entregue lo prometido.

La propuesta técnica con alcance cerrado

Una propuesta comercial habla de beneficios. Una propuesta técnica describe, con precisión, qué se va a construir, con qué límites, con qué integraciones y con qué queda explícitamente fuera del alcance. La diferencia importa porque la mayoría de disputas entre empresa y proveedor de IA no son sobre calidad: son sobre qué se entendió que estaba incluido y qué no.

• Alcance funcional detallado: qué procesos automatiza o asiste el sistema, y en qué casos sigue interviniendo una persona.
• Integraciones específicas con los sistemas actuales de la empresa (CRM, ERP, bases de datos), nombradas una por una, no como “integración con sistemas existentes”.
• Lista explícita de lo que NO incluye la propuesta: es tan importante como la lista de lo que sí incluye.
• Supuestos y dependencias: qué necesita entregar la empresa (datos limpios, accesos, personal disponible) para que el cronograma se cumpla.

El plan de medición del resultado

Este documento responde la pregunta que casi nunca se responde por escrito: ¿cómo se va a saber si el proyecto funcionó? Debe nombrar la métrica de negocio (no la métrica técnica del modelo), la línea base antes del proyecto, la forma en que se va a medir después y quién del lado de la empresa va a validar esa medición. Sin este plan, cualquier proveedor puede declarar éxito al final del contrato sin que exista una forma objetiva de confirmarlo o refutarlo.

El cronograma por hitos y el SLA

El cronograma por hitos divide el proyecto en entregables verificables, cada uno con una fecha y un criterio de aceptación, en lugar de una sola fecha de “entrega final” que oculta meses de trabajo sin visibilidad. El SLA define qué pasa después de la entrega: tiempo de respuesta ante fallas, disponibilidad mínima del sistema y penalidades si el proveedor no cumple. Un proveedor que solo ofrece “soporte cuando lo necesiten”, sin tiempos ni compromisos escritos, está ofreciendo una promesa, no un servicio.

El documento más olvidado y más caro: quién es dueño del sistema

De todos los documentos de esta lista, el acuerdo de propiedad sobre el sistema es el que más se pasa por alto y el que más caro sale no exigir. La razón es simple: durante la negociación, la conversación se concentra en el precio, el alcance y el tiempo de entrega. Nadie quiere “complicar” la firma preguntando qué pasa cuando la relación termine, porque en ese momento el foco está en empezar, no en terminar.

El problema aparece cuando la empresa decide que quiere cambiar de proveedor, o que quiere llevar el sistema internamente, o simplemente que quiere auditar cómo funciona el modelo que está tomando decisiones sobre sus clientes. Si el sistema vive dentro de una plataforma propietaria del proveedor, construido con herramientas que solo el proveedor sabe operar, y sin un acuerdo que obligue a la portabilidad, la empresa descubre que no puede irse. No porque el contrato lo prohíba explícitamente, sino porque nadie definió cómo hacerlo posible.

Esto se llama dependencia de proveedor, y en proyectos de IA es más grave que en software tradicional, porque el sistema no es solo código: incluye datos de ajuste, configuraciones específicas del negocio y, muchas veces, el conocimiento operativo que el proveedor acumuló sobre los procesos internos de la empresa. Perder acceso a eso no es un inconveniente técnico. Es perder el control sobre una parte del negocio que ya depende de ese sistema para funcionar.

Negociar esto antes de firmar no requiere desconfianza ni agresividad. Requiere una pregunta directa: si esta relación termina en dieciocho meses, ¿qué se lleva la empresa y qué se queda el proveedor? Un proveedor que responde esa pregunta con claridad y por escrito es un proveedor con el que vale la pena trabajar. Uno que la evade, o que la responde con “no te preocupes, siempre trabajamos así”, ya dio la respuesta.

Cómo se ve en la práctica

Una empresa de distribución de insumos industriales, cerca de noventa personas, en Perú, contrató a un proveedor para automatizar la atención de primer nivel a sus clientes: cotizaciones simples, seguimiento de pedidos y respuestas a preguntas frecuentes, con un asistente basado en IA generativa conectado a su catálogo. El proveedor mostró un caso de éxito con un logo reconocido del sector retail y una demo que funcionaba bien. El área comercial, entusiasmada, presionó para cerrar rápido.

El contrato que se firmó fue el contrato de servicios estándar del proveedor, sin ningún acuerdo de propiedad sobre el sistema ni sobre los datos de conversaciones que se iban a acumular. El asistente se construyó sobre una plataforma propia del proveedor: los flujos de conversación, las reglas de negocio y las integraciones con el catálogo vivían ahí, no en la infraestructura de la empresa. Nadie en compras ni en legal marcó esto como un problema, porque el contrato hablaba de “servicio gestionado”, y eso sonaba razonable.

Catorce meses después, el proveedor subió el precio mensual de forma considerable, alegando “nuevos costos de infraestructura”. La empresa quiso migrar a otro proveedor más económico y descubrió que no podía: los flujos de conversación no eran exportables en un formato que otro proveedor pudiera reconstruir, y el historial de conversaciones (la fuente para seguir ajustando el asistente) tampoco. Migrar significaba, en la práctica, empezar de cero: perder meses de ajuste fino y el conocimiento acumulado sobre qué preguntaban realmente sus clientes.

La empresa terminó negociando una salida costosa: pagó una tarifa de “transición” al proveedor original solo para obtener una exportación parcial de los datos, y tardó varios meses en tener un asistente equivalente funcionando con un nuevo proveedor, esta vez con un acuerdo de propiedad y de portabilidad firmado desde el día uno. El costo real no fue la tarifa de salida: fue el tiempo perdido y la dependencia que se pudo evitar con un documento de dos páginas que nadie pidió a tiempo.

Mi criterio

Cómo saber si lo hiciste bien

No se trata de acumular papel por acumularlo. Se trata de que, antes de firmar, la empresa pueda responder con evidencia concreta a las preguntas que de verdad importan: quién es dueño de qué, cómo se mide el resultado y qué pasa si la relación termina.

• Existe un acuerdo firmado de propiedad sobre el código, los modelos ajustados y los datos, no solo una licencia de uso.
• Hay un plan de tratamiento y borrado de datos con plazos concretos, no una promesa verbal de “cuidamos tu información”.
• El plan de medición del resultado nombra la métrica de negocio, la línea base y quién la valida, antes de que el proyecto empiece.
• El cronograma tiene hitos verificables con criterios de aceptación, no una sola fecha de entrega final.
• Se pudo verificar al menos un caso anterior con un contacto real, no solo con un logo en una lámina.

Si alguno de estos puntos no se puede marcar antes de firmar, la recomendación es simple: no firmar todavía. Pedir el documento que falta cuesta un correo y unos días de espera. No pedirlo puede costar, como en el caso anterior, meses de dependencia y una migración forzada que se pudo evitar.