Cómo redactar los términos de referencia (TDR) para un servicio de IA

El error que arruina el proceso antes de recibir la primera propuesta

El error más común no ocurre cuando llegan las propuestas. Ocurre antes, cuando alguien en compras abre la plantilla de un TDR que usaron para comprar el ERP o el CRM del año pasado, le cambia el título a “servicio de inteligencia artificial” y llena los espacios en blanco con requisitos técnicos genéricos: “debe usar procesamiento de lenguaje natural”, “debe integrar modelos de machine learning”, “debe contar con arquitectura escalable”. Nadie preguntó primero cuál es el problema de negocio que hay que resolver.

El resultado de ese atajo se ve tres o cuatro semanas después, cuando llegan cinco propuestas que no se pueden comparar entre sí. Un proveedor entendió que el problema era automatizar respuestas de atención al cliente. Otro entendió que el problema era generar reportes. Un tercero directamente vendió una plataforma genérica con la etiqueta “IA” pegada encima. El comité de evaluación se sienta a comparar cosas distintas y termina, casi siempre, decidiendo por el precio, porque es el único criterio que sí resulta comparable entre las cinco propuestas.

Ese es el costo real de un TDR mal escrito: no es que el proceso tarde más, es que el proceso deja de servir para lo que existe, que es elegir al proveedor que mejor resuelve el problema, no al que mejor interpretó (o adivinó) lo que el comité quiso decir.

Y cuando la adjudicación se cuestiona (en una auditoría interna, en un directorio, en una entidad pública ante un órgano de control) el TDR es el primer documento que se revisa. Si no define con claridad el problema, el resultado esperado y los criterios de evaluación, no hay defensa posible: la adjudicación se sostiene en la memoria de quien la firmó, no en un documento que cualquiera pueda auditar.

Qué es un TDR para un servicio de IA (y qué no)

Un TDR (términos de referencia) es el documento que fija, antes de invitar a nadie a proponer, cuál es el problema que se quiere resolver, qué resultado se espera, qué reglas rigen la comparación de propuestas y qué se le va a exigir al proveedor que gane. No es un documento de tecnología: es un documento de criterio de negocio traducido a reglas de compra.

La función del TDR no es demostrar que el comité sabe de inteligencia artificial. Es exactamente la contraria: obligar a que cada proveedor traduzca su propuesta al lenguaje del problema, y no al revés.

• No es una ficha técnica de funcionalidades: “debe tener dashboard”, “debe usar determinado modelo” describen herramientas, no resultados, y no deberían ser el centro del documento.
• No es una plantilla genérica con el logo cambiado: si el mismo TDR sirve para comprar un ERP, una impresora o un servicio de IA, no está haciendo su trabajo.
• No es el contrato: las cláusulas legales, penalidades y condiciones de pago vienen después; el TDR define qué se compra y cómo se compara, no las condiciones jurídicas finales.
• No es una invitación abierta a interpretación: si dos proveedores serios pueden leer el mismo TDR y entender alcances distintos, el documento está incompleto.
• No es un trámite exclusivo de compras: un TDR escrito sin el área que sufre el problema es, con altísima probabilidad, un TDR que no sirve.

El problema de negocio, el contexto y el objetivo medible

Todo TDR de un servicio de IA debería abrir con una sección que muchos saltan: el contexto del problema, escrito en el lenguaje del área que lo sufre, no en el lenguaje de sistemas. Qué proceso duele, desde cuándo, con qué frecuencia y con qué consecuencia para el negocio.

Por qué empezar en el dolor y no en la tecnología

Si el TDR abre describiendo “se requiere implementar una solución de inteligencia artificial generativa” antes de explicar qué proceso está roto, ya se perdió el control del documento. Cualquier proveedor puede vender “una solución de inteligencia artificial generativa”. Muy pocos pueden resolver, por ejemplo, que el área de créditos tarda demasiados días en resolver una solicitud porque revisa a mano decenas de documentos por expediente. El segundo problema es específico, medible y comparable. El primero es una frase de folleto.

Cómo escribir un objetivo que se pueda medir

El objetivo del TDR no puede ser “mejorar la eficiencia con inteligencia artificial”. Tiene que ser un objetivo con verbo, proceso y dirección de cambio.

• Nombra el proceso concreto: qué proceso de negocio duele hoy (tiempo de respuesta a un reclamo, tasa de rechazo de una solicitud, horas dedicadas a conciliar información entre áreas).
• Cuantifica el estado actual, aunque sea con una estimación interna razonable: cuánto cuesta hoy el problema en tiempo, en dinero o en errores que se repiten.
• Define el resultado esperado con un número o un rango: qué indicador se mueve y en qué dirección se espera que se mueva.
• Fija un horizonte realista: en cuánto tiempo se espera empezar a ver ese movimiento, diferenciando el piloto del despliegue completo.
• Nombra al dueño del proceso dentro de la organización, no al área de sistemas, como responsable de validar si el resultado se cumplió.

Alcance: qué entra, qué no entra y los entregables

El alcance es la sección donde más TDR fallan, porque se escribe en abstracto (“automatización de procesos con IA”) en lugar de escribirse en concreto: qué sistemas, qué volúmenes, qué usuarios, qué límites.

• Los procesos y sistemas que toca el servicio, y los que quedan expresamente fuera: un alcance sin límites explícitos es un alcance que va a crecer sin control durante la ejecución.
• Los volúmenes reales de operación: cuántos casos, transacciones o usuarios procesa hoy el proceso, para que el proveedor dimensione una propuesta seria y no una genérica.
• Las integraciones necesarias con sistemas existentes, y quién es responsable de proveer accesos, documentación técnica y soporte durante la implementación.
• Los entregables tangibles por fase, no solo la palabra “implementación”: qué se entrega, en qué formato y con qué evidencia de funcionamiento.
• El criterio de aceptación de cada entregable, y quién lo firma: sin esto, “entregado” significa cosas distintas para el proveedor y para el cliente.

El costo de dejar el alcance abierto

Un alcance ambiguo no ahorra tiempo al redactar el TDR: lo traslada, con intereses, a la etapa de ejecución. Ahí aparece la negociación eterna sobre qué estaba “incluido”, el cambio de alcance no presupuestado y, con frecuencia, el proyecto que se estira el doble del plazo original porque nadie definió, desde el inicio, dónde terminaba el servicio.

Propiedad de datos, propiedad del sistema y requisitos de seguridad

Esta es la sección que más se salta un TDR copiado de otra industria, y es la que más caro sale omitir. Antes de firmar hay que declarar quién es dueño de qué: de los datos, del sistema resultante y de la relación con el proveedor si algún día esa relación termina.

• Propiedad de los datos usados para configurar, afinar o alimentar el sistema: quién los aporta, dónde se almacenan y qué puede hacer el proveedor con ellos después de terminado el contrato.
• Propiedad del código, prompts, configuraciones y flujos desarrollados a medida para la organización: si el proveedor se va, ¿el cliente se queda con eso o vuelve a empezar de cero?
• Condiciones de portabilidad: qué pasa si se decide cambiar de proveedor. Un buen TDR exige, desde el inicio, que la salida sea posible sin rehacer todo el trabajo.
• Tratamiento de datos sensibles: dónde se procesan y almacenan (dentro o fuera del país), y bajo qué marco de protección de datos personales aplican las normas locales.
• Nivel de acceso del proveedor a sistemas productivos: qué credenciales, qué ambientes (prueba o producción) y con qué registro de auditoría de cada acción.

Seguridad no es una casilla que se marca al final

Pedir “certificaciones de seguridad” como requisito genérico no sirve de nada si nadie revisa qué certificación aplica al riesgo real del proceso. Un TDR serio pregunta por el riesgo concreto (si el proceso toca datos personales, datos financieros o decisiones que afectan a una persona, como aprobar o rechazar un crédito) y ajusta los requisitos de seguridad a ese riesgo, no a una lista copiada de otro documento.

Criterios de evaluación con pesos y cronograma por fases

Un TDR sin pesos declarados por criterio no es un TDR, es una invitación a que la adjudicación se decida en una conversación de pasillo. Los pesos hay que fijarlos antes de recibir la primera propuesta, no después de verlas, para que nadie pueda ajustar el criterio a modo del proveedor que ya tenía en mente.

• Entendimiento del problema de negocio: qué tan bien la propuesta demuestra haber entendido el proceso, no solo el nombre del proyecto (peso sugerido: entre 20 y 30 por ciento).
• Metodología y plan de implementación: cómo va a llegar del diagnóstico al resultado, con qué fases y qué validaciones intermedias (entre 15 y 20 por ciento).
• Experiencia comprobable en problemas similares, no en la industria en general: referencias verificables de un proceso parecido resuelto antes (entre 15 y 20 por ciento).
• Propuesta económica, entendida como parte del criterio y no como el único criterio (entre 15 y 20 por ciento).
• Cronograma y capacidad real de entrega por fases, incluyendo qué pasa si una fase no cumple el criterio de salida (entre 10 y 15 por ciento).

Un cronograma por fases, no un “todo o nada”

El cronograma de un servicio de IA serio no entrega todo al final. Se divide en fases con criterio de salida propio: diagnóstico y validación del problema, piloto acotado con un proceso o una unidad de negocio, escalamiento progresivo si el piloto cumple el resultado esperado, y cierre con transferencia de conocimiento y del sistema al equipo interno. Cada fase debería tener un punto de decisión explícito: seguir, ajustar o detener, según evidencia y no según inercia contractual.

Cómo se ve en la práctica

Una entidad financiera mediana, con operaciones en Perú y alrededor de doscientos empleados, llevaba dos procesos de compra de “soluciones de inteligencia artificial” frustrados. En ambos casos el TDR se había redactado copiando un documento previo de compra de software, cambiando el título y agregando una lista de tecnologías de moda. Las propuestas que llegaron fueron, literalmente, incomparables: una ofrecía un chatbot de atención, otra un módulo de analítica de riesgo, ninguna resolvía el problema que en realidad quería atacar el área de operaciones, que era el tiempo que tardaba en resolverse una solicitud de crédito por la revisión manual de documentos.

En el tercer intento, el área de operaciones se sentó con compras antes de escribir una sola línea del TDR. Definieron el problema en una frase: el tiempo de resolución de una solicitud estaba concentrado en la revisión manual de documentos de sustento, no en la decisión final. Escribieron el objetivo con un verbo, un proceso y una dirección de cambio, sin inventar una cifra exacta que nadie podía sostener todavía. Definieron el alcance: qué tipos de solicitud entraban al piloto y cuáles quedaban fuera, qué integraciones se necesitaban con el sistema de créditos existente y qué pasaba con los datos personales de los solicitantes.

El TDR resultante no mencionaba ninguna tecnología por nombre. Mencionaba el proceso, el resultado esperado, el alcance del piloto y los criterios de evaluación con sus pesos, incluyendo un peso alto para “entendimiento del problema de negocio”. Recibieron tres propuestas y, por primera vez, el comité pudo compararlas en la misma tabla: mismo problema entendido, mismas fases, mismos criterios de aceptación. La adjudicación se decidió por la calidad del plan de implementación y la experiencia comprobable, no por quién cotizó más barato.

El resultado no fue una revolución instantánea. Fue un piloto acotado, con un criterio de salida claro antes de escalar, y un comité que por primera vez pudo defender la decisión con el documento en la mano, no con la memoria de la reunión.

Mi criterio

Cómo saber si lo hiciste bien

Un TDR bien escrito se nota antes de recibir la primera propuesta: cualquier persona del comité, sin formación técnica, puede leerlo y explicar en dos frases qué problema se quiere resolver y cómo se va a decidir el ganador.

• El área que sufre el problema participó en escribirlo, no solo lo revisó al final.
• El objetivo tiene un verbo, un proceso y una dirección de cambio, no solo la palabra “eficiencia”.
• El alcance dice explícitamente qué queda fuera, no solo qué queda dentro.
• Los criterios de evaluación tienen pesos declarados antes de recibir propuestas, no después.
• Ninguna sección exige una tecnología o marca específica sin justificar por qué esa exigencia es necesaria para el resultado.

Si al releer el TDR aparece una sección que solo un ingeniero entendería, o un requisito que solo un proveedor específico podría cumplir, todavía no está listo. Vuelve al problema de negocio, escribe desde ahí y deja que la tecnología aparezca donde corresponde: en la propuesta del proveedor, no en el documento que la invita.