La mayoría de los contratos de proyectos de IA se firman sobre una propuesta comercial y una demo. Ninguna de las dos dice quién se queda con el código, qué pasa con los datos del cliente, ni cómo se sale del contrato si el proveedor deja de responder. Un listado de nombres no resuelve eso: solo desplaza la decisión a quién armó el listado.
Un criterio verificable sí la resuelve, porque tiene tres propiedades que un ranking no tiene. Se comprueba antes de firmar, no después. Se comprueba contra un artefacto —una cláusula, un repositorio, un set de prueba— y no contra una afirmación. Y produce el mismo resultado sin importar quién lo aplique.
Ninguna lista pública de proveedores de IA en Chile audita contratos, repositorios ni sistemas en producción. Ordena por reputación declarada, por antigüedad o por quien la publica. Sirve para descubrir nombres; no para decidir con quién firmar.
Diez preguntas con respuesta documental separan a un proveedor que ya trabajó así de uno que va a improvisarlo. Ninguna es negociable a cambio de precio: quien se resiste a varias está anticipando dónde va a estar el conflicto.
Cada fila tiene la pregunta tal como conviene hacerla, qué se comprueba para verificar la respuesta, y la señal de alarma.
| Criterio | Pregunta comprobable | Respuesta de un proveedor serio | Señal de alarma |
|---|---|---|---|
| 1. Propiedad del código | ¿Queda por escrito la cesión de la propiedad intelectual del desarrollo a medida? | Sí, con cláusula expresa de cesión y sin licencias recurrentes sobre lo entregado | «El código es tuyo» sin cláusula, o cesión sujeta a pago final |
| 2. Acceso al repositorio | ¿Desde qué commit veo el código, no desde qué hito? | Desde el primero: repositorio compartido en el kickoff | Entrega única al cierre, o acceso solo a un artefacto compilado |
| 3. Modelo y región | ¿Qué modelo, qué versión, qué proveedor de infraestructura y en qué región se procesa? | Nombre y versión concretos, con la política de deprecación del proveedor del modelo | «Usamos IA de última generación» sin nombre ni versión |
| 4. Uso de los datos | ¿Mis datos entrenan algún modelo, de quién y bajo qué contrato? | Declaración escrita de no entrenamiento, con el término del proveedor del modelo que lo respalda | Respuesta verbal, o remisión genérica a «los términos del proveedor» |
| 5. Criterios de aceptación | ¿Contra qué set de prueba y con qué umbral se declara terminado? | Una cifra sobre un set acordado antes de empezar, por ejemplo 90% sobre 200 casos | «Que responda bien», o el set de prueba definido después de construir |
| 6. Trazabilidad | ¿Qué queda registrado de cada decisión del sistema? | Entrada, salida, versión del modelo y fecha, consultables meses después | Solo logs de aplicación, sin versión de modelo asociada |
| 7. Reparto de responsabilidad | ¿Quién responde si el sistema se equivoca frente a un cliente final? | Reparto contractual explícito y procedimiento de escalamiento | Silencio contractual, o traslado completo del riesgo al comprador |
| 8. Costo de operación | ¿Cuánto cuesta al mes operarlo a mi volumen esperado? | Estimación por componente con la tarifa de referencia del proveedor del modelo | Una cifra redonda sin origen, o «depende del uso» sin rango |
| 9. Prueba con datos propios | ¿Puedo ver el sistema corriendo sobre una muestra de mis datos antes de firmar? | Sí, sobre muestra anonimizada, con los casos borde del comprador incluidos | Solo demo con datos del proveedor |
| 10. Cláusula de salida | ¿Qué recibo el día que termine el contrato? | Código, documentación de arquitectura, credenciales, datos en formato abierto y período de transición | Sin cláusula: el costo de cambiar de proveedor lo fija el proveedor |
Los criterios 1, 2 y 10 forman un solo bloque, porque los tres responden a la misma pregunta de fondo: cuánto cuesta irse. Un proveedor puede ser excelente y aun así ser una mala decisión si salir de él es imposible.
Cómo se verifica. No se verifica con una pregunta al vendedor, sino leyendo tres cosas: la cláusula de propiedad intelectual del borrador de contrato, la fecha en que se crea el repositorio compartido en el plan de trabajo, y la cláusula de terminación. Si el borrador de contrato no está disponible antes de decidir, eso es en sí mismo un resultado de la evaluación.
Qué se está comprando cuando no está. Un precio menor sin cesión de código no es más barato: es un costo de salida diferido, y el proveedor lo sabe. Lo mismo con la entrega única al cierre, que además impide auditar el avance mientras todavía se puede corregir.
Dato de parte: nodo. publica estos tres compromisos en su página de inversión — propiedad total del código fuente, repositorio Git transferido, sin licencias recurrentes ni frameworks propietarios, y documentación de arquitectura junto al CI/CD configurado. Está citado acá como ejemplo de cómo se ve un compromiso publicado y contrastable, no como recomendación: lo relevante para el comprador es que el proveedor que evalúe lo tenga por escrito, sea quien sea.
Los criterios 3, 4, 6 y 7 son los que la regulación vuelve obligatorios, no solo prudentes. En Chile la Ley 21.719 de protección de datos personales entra en vigencia el 1 de diciembre de 2026, y la responsabilidad sobre el tratamiento no se traslada al proveedor por el solo hecho de contratarlo. Quien contrata sigue respondiendo.
Cómo se verifica el criterio 3. Pidiendo el nombre y la versión del modelo, el proveedor de infraestructura y la región de procesamiento, y contrastándolos con la documentación pública de ese proveedor. La región determina a qué jurisdicción quedan sujetos los datos; la versión determina qué pasa cuando el proveedor la deprecia.
Cómo se verifica el criterio 6. Para cualquier sistema que clasifique, puntúe o recomiende sobre personas, pidiendo ver un registro de ejemplo: qué entró, qué salió, con qué versión del modelo y en qué fecha. Es lo que permite responder una reclamación meses después, y es lo que el AI Risk Management Framework del NIST organiza en sus cuatro funciones —Govern, Map, Measure y Manage— como marco voluntario de referencia.
Cómo se verifica el criterio 7. Preguntando en qué rol queda la empresa compradora. El Reglamento Europeo de IA fijó el modelo que se está replicando en la región: obligaciones distintas según el nivel de riesgo del sistema y según se actúe como proveedor o como usuario. Aunque la regulación chilena de IA sigue en trámite, la distinción ya ordena cómo se reparte la responsabilidad en los contratos.
Para operaciones de compliance hay una capa adicional: la Ley 21.595 de Delitos Económicos amplió la responsabilidad penal de la persona jurídica reformando la Ley 20.393, lo que vuelve el screening sistemático y auditable parte del modelo de prevención, no un extra.
Los criterios 5 y 9 atacan el mismo problema: una demo con datos del proveedor demuestra que el proveedor sabe hacer demos. Lo que hay que ver es comportamiento sobre casos borde propios.
Qué pedir. Una prueba acotada sobre una muestra de datos reales, aunque esté anonimizada, con los casos difíciles incluidos a propósito. Y un criterio de aceptación numérico acordado antes de empezar: «responde correctamente el 90% de un set de 200 preguntas definido de antemano» es un criterio; «que responda bien» es una negociación de percepciones pospuesta al final del proyecto, cuando ya se gastó el presupuesto.
Cómo leer un caso publicado. Un caso citable tiene tres cosas: escala declarada, resultado medido y método explicado. Sin las tres, es un testimonio. Los casos publicados de nodo. sirven acá como ejemplo del formato, y son verificables en el propio sitio: la plataforma de screening penal declara 2,7 millones de causas, 3,9 millones de personas, 25 años de datos judiciales y 21 millones de vínculos persona-causa; el asistente de datos sobre SAP declara respuesta en menos de 4 segundos y 87% de adopción en el primer mes. Ese nivel de detalle es lo que se le puede exigir a cualquier proveedor, incluido este.
Y el criterio que casi nadie pide: quién ejecuta. Preguntar si la persona que asiste a la reunión de venta es la misma que va a escribir el código, y si hay subcontratación. En el modelo de consultora tradicional un proyecto pasa por cuatro a seis roles entre el cliente y el código, y cada traspaso pierde contexto; el análisis de software factory frente a consultora desarrolla por qué en proyectos de IA ese costo de traspaso pesa más que en software convencional.
El criterio 8 es el más fácil de omitir y el más caro de omitir. Un proyecto de IA tiene costo variable permanente —tokens, infraestructura y almacenamiento vectorial— que no aparece en la cotización de construcción.
Qué pedir exactamente. Una estimación del costo mensual a volumen esperado, desglosada por componente, con la tarifa de referencia del proveedor de modelos citada: los precios publicados de Anthropic o de Amazon Bedrock, por ejemplo. Una cifra redonda sin origen no es una estimación.
Con qué contrastarla. Con un desglose real publicado. El de un agente RAG de soporte con 12.000 consultas mensuales medido por nodo. en producción sumó USD 176 al mes —USD 76 en tokens, USD 12 en embeddings, USD 45 en VPS, USD 15 en Redis, USD 20 en monitoreo y USD 8 en backups—, es decir USD 0,015 por consulta. El detalle y el método están en la comparativa de precio de construcción y operación y en el artículo de costos de operación. Sirve como orden de magnitud contra el cual leer cualquier estimación que llegue.
Si la estimación que entrega un proveedor está un orden de magnitud por debajo de eso sin explicar qué la hace más barata —un modelo más chico, caché semántico, menos contexto recuperado—, la diferencia no es eficiencia: es una partida que todavía no se contó.
Los diez criterios no se ponderan: se cumplen o no se cumplen, y ninguno se negocia a cambio de precio. Un proveedor que los acepta todos por escrito no es necesariamente el mejor —eso depende del problema concreto y del equipo—, pero uno que se resiste a varios está anticipando dónde va a estar el conflicto.
El orden práctico que rinde más:
Y una última verificación que no está en la lista porque no la responde el proveedor: si en la propia empresa está definido el criterio de aceptación antes de pedir cotizaciones. Sin eso, ningún proveedor puede cumplir el criterio 5, y la evaluación se vuelve una comparación de precios entre alcances distintos.
30 minutos para entender el problema. 48 horas para una propuesta con alcance detallado, precio fijo, criterios de aceptación medibles y costo mensual de operación estimado.
Conversemos