amBrain
FinTechOct 12, 202610 min de lectura

Un proyecto de IA llave en mano: cuándo funciona un precio cerrado y cómo contratar a una empresa que lleve tu piloto a producción

Contratos de IAExternalizar la IAProcesamiento de documentosQuién la construye
Error al cargar la imagen

Empieza con una evaluación a precio cerrado del piloto con tus documentos. Después paga por horas, con un tope, para subir su puntuación, y acuerda un precio cerrado para el trabajo que puedas describir.

Un piloto de IA atascado puede terminarse como un proyecto llave en mano, en el que al final se entrega un sistema que funciona. Empieza con una evaluación breve a precio cerrado que mida el piloto con tus documentos y fije la puntuación que debe alcanzar. Subir la puntuación hasta ese objetivo es un trabajo que nadie puede presupuestar de antemano, así que contrátalo por tiempo y materiales: tarifas por hora con un tope para el total. Pon precio cerrado al resto, el trabajo que puedes describir sobre el papel, fase a fase.

La respuesta corta: contrata primero una evaluación a precio cerrado, y no aceptes un precio único para todo el trabajo antes de que la empresa haya probado el piloto con tus documentos. Después, fija el precio de cada fase que pueda describirse de antemano, y paga por horas, con un tope, el trabajo de subir la puntuación. Paga una fase de precio cerrado solo cuando el sistema supere una prueba acordada con tus documentos, y conserva el derecho a parar entre fases.

¿Qué significa «llave en mano» en un sistema de IA?

En un sistema de IA, llave en mano significa que la empresa entrega un sistema listo para usar, y el contrato dice qué significa «listo». Por ejemplo, el sistema se ejecuta dentro de tu perímetro, en servidores o cuentas en la nube que controla tu empresa. Alcanza la puntuación objetivo con tus documentos y envía los casos dudosos a una persona. Tu personal puede operarlo una vez que la empresa se ha ido.

En la construcción, un contratista llave en mano diseña y construye toda la instalación y la entrega lista para usar. La FIDIC, la Federación Internacional de Ingenieros Consultores, publica un contrato estándar para este tipo de proyectos, conocido como Libro Plata (Silver Book).

La página de la FIDIC sobre la edición de 2017 menciona tres casos en los que el Libro Plata no encaja:

  • Los licitadores no tienen el tiempo ni la información necesarios para comprobar lo que exige el cliente, hacer sus propios estudios de diseño y de riesgos y estimar el coste
  • Buena parte de la obra es subterránea o está en otros lugares que los licitadores no pueden inspeccionar, salvo que el contrato cubra condiciones que nadie podía prever
  • El cliente piensa supervisar o controlar de cerca el trabajo del contratista, o revisar la mayoría de los planos

Para estos casos, la FIDIC recomienda otro contrato estándar, su Libro Amarillo (Yellow Book). Un piloto de IA atascado encaja en los dos primeros casos hasta que una empresa haya pasado tus documentos por él, porque nadie ha inspeccionado el terreno. El contrato por fases que se describe abajo encaja en el tercero, ya que te deja controlar de cerca el trabajo. Así que entiende «llave en mano» como la entrega de un sistema que funciona, y pon precio al trabajo fase a fase.

¿Por qué es difícil poner precio cerrado a un trabajo de IA?

Muchas partes de un proyecto de software pueden describirse antes de que nadie las construya. Un informe, o una conexión con otro sistema, cabe en un papel, y una empresa puede poner precio a lo que está escrito.

Un sistema que lee documentos con un modelo de lenguaje tiene una parte que nadie puede describir de antemano: con qué frecuencia lee bien cada campo en tus documentos. Un campo es un dato concreto, como una fecha o un importe. La respuesta depende de tus escaneos y tus plantillas, y de casos que nadie recuerda hasta que aparecen. Nadie sabe cuánto trabajo costará llegar a la puntuación objetivo hasta que alguien mida el sistema con tus documentos.

Las normas de compras públicas del Gobierno de Estados Unidos también hacen esta distinción. La parte 16 del Federal Acquisition Regulation (FAR), el reglamento que rige esas compras, trata de los tipos de contrato. Describe el contrato de tiempo y materiales como aquel que se paga a tarifas horarias fijas por las horas trabajadas, más el coste real de los materiales. Solo permite este tipo de contrato cuando nadie puede estimar con precisión el trabajo al firmar, ni prever su coste «con un grado razonable de confianza».

Según el FAR, un contrato de precio cerrado conviene a trabajos con especificaciones claras, en los que se puede fijar un precio justo desde el principio. La parte 16 también pide a los responsables de contratación que no prolonguen el uso de tiempo y materiales una vez que la experiencia ofrezca una base para fijar precios más firmes.

Por eso, un precio cerrado para todo el trabajo, presupuestado antes de que nadie haya pasado tus documentos por el sistema, suele llevar un margen grande para lo desconocido. La alternativa es una lista de exclusiones, cosas que el precio no cubre, y cada una te devuelve un riesgo. Busca las dos cosas en la propuesta.

¿Qué etapas encajan con un precio cerrado y cuáles con tiempo y materiales?

Esto no es asesoramiento jurídico. El contrato lo redacta tu abogado, y este artículo enumera lo que debería cubrir. Divide el trabajo y pon precio a cada parte según lo que se sepa cuando empiece:

  • Empieza con una evaluación a precio cerrado. La empresa lee el código del piloto, lo ejecuta con una muestra de tus documentos reales dentro de tu perímetro y después pone por escrito por qué se atascó. Recibes un borrador del conjunto de aceptación (un grupo de tus documentos reales con la respuesta correcta de cada uno) y un plan con precio para la siguiente fase. Las dos cosas son tuyas, continúes o no
  • La fase intermedia, subir la puntuación, es la incierta. Le va bien el modelo de tiempo y materiales con un techo: un tope para el total que puede facturar la empresa. La empresa prueba distintos prompts (las instrucciones escritas que sigue el modelo) y distintos modelos con el conjunto de aceptación y te enseña las puntuaciones cada semana. Puedes parar cuando el avance se estanque
  • Una vez alcanzada la puntuación objetivo, el resto es ingeniería corriente, con precio cerrado por fases. Incluye instalar el sistema dentro de tu perímetro, las alertas cuando baja la calidad, la cola de revisión en la que el personal comprueba los casos dudosos y el paso de tu equipo al nuevo sistema. Cada fase de precio cerrado termina con una prueba de aceptación: se puntúa el sistema con el conjunto de aceptación y el resultado decide si la fase se paga
  • Tras el lanzamiento, para operar el sistema conviene una cuota mensual con una lista escrita de lo que cubre, porque alguien tiene que vigilar la calidad y ocuparse de las actualizaciones del modelo

El FAR también exige que un contrato de tiempo y materiales incluya «un precio máximo que el contratista supera por su cuenta y riesgo». Pon también un techo en tu contrato. Limita lo que pagas, pero según la propia cláusula de pago del FAR, la empresa no está obligada a seguir trabajando una vez alcanzado el techo, salvo que lo subas. Acuerda de antemano qué pasa entonces: paras, subes el techo o vuelves a planificar el trabajo.

Una empresa puede ofrecer toda la secuencia como un único contrato y llamarlo llave en mano. Eso puede funcionar si cada fase tiene su propio precio y su propia prueba de aceptación, y puedes parar entre una fase y otra.

¿Qué debe significar «terminado» en el contrato?

«Terminado» significa que el sistema supera su prueba de aceptación, puntuada frente a un umbral de aprobación acordado antes de fijar el precio. El contrato debería concretar:

  • Qué documentos forman el conjunto de aceptación, cuántos hay de cada tipo y quién anotó las respuestas correctas. El conjunto queda congelado una vez fijado el precio de la fase
  • El umbral de aprobación de cada campo y de cada tipo de documento, que juntos forman la puntuación objetivo, y los campos que siempre van a una persona, sea cual sea la puntuación
  • Dónde se hace la prueba de aceptación y quién la hace. Se hace dentro de tu perímetro, con la versión exacta que entregará la empresa. La lleva a cabo tu personal, o la empresa delante de tu personal
  • Qué pasa si el sistema no supera su prueba de aceptación. La empresa tiene un plazo fijado para corregirlo a su costa. Pasado ese plazo, puedes parar y quedarte con lo construido

Mantén una parte del conjunto de aceptación fuera del alcance de la empresa hasta la prueba de aceptación. Si la empresa ha visto todos los documentos de prueba, puede ajustar el sistema a esos documentos concretos, y la puntuación exagerará lo bien que lee documentos nuevos. El artículo sobre los pilotos de IA que nunca llegaron a producción, enlazado arriba, explica cómo construir el conjunto.

¿Qué puede romper más adelante un contrato de IA a precio cerrado?

Acuerda de antemano cómo cambian el precio estas situaciones:

  • Tipos de documento o plantillas nuevos que no están en el conjunto de aceptación. Trátalos como cambios, con un precio fijado del mismo modo que el de las fases
  • La retirada, por parte del proveedor, del modelo que usa el sistema. La página de obsolescencia de modelos (deprecations) de OpenAI, por ejemplo, fija un preaviso de al menos seis meses para un modelo con disponibilidad general y de al menos tres meses para sus variantes especializadas. Los modelos en versión preliminar pueden retirarse con un preaviso mucho más corto, y motivos de seguridad o de cumplimiento pueden acortar cualquiera de estos plazos. Deja por escrito quién paga la prueba del sustituto con el conjunto de aceptación y el cambio al nuevo modelo
  • Retrasos de tu lado, como una aprobación lenta del acceso de la empresa a tus sistemas, o la entrega tardía de los documentos y las respuestas correctas que necesita la empresa. Un precio cerrado da por hecho que tu parte llega a tiempo, así que enumera lo que tiene que entregar tu empresa y para cuándo
  • Un cambio en tus propias normas, por ejemplo que tu equipo de riesgos decida que una clase de documentos ya no puede ir a un modelo externo. Esos documentos pasan entonces a procesarse dentro de tu perímetro, y eso cambia el trabajo y su precio

Los costes de operación quedan fuera del precio de construcción, salvo que el contrato diga otra cosa. Las tarifas por uso del modelo, o el coste de los servidores que lo ejecutan, crecen con el número de documentos. Acuerda quién los paga durante la construcción y después del lanzamiento, y cuántos documentos al mes da por supuestos el precio.

¿Cómo vinculamos los pagos a los resultados?

Vincula cada pago de precio cerrado a que el sistema supere su prueba de aceptación dentro de tu perímetro, y no dejes que ninguno de esos pagos venza solo porque llegue una fecha. En la fase de tiempo y materiales pagas las horas hasta el techo, y las puntuaciones semanales te dicen si conviene seguir.

Retén una parte del pago final hasta que el sistema haya funcionado en producción durante un periodo acordado sin bajar de la puntuación objetivo. Acuerda el porcentaje y el periodo antes de firmar.

Conserva el derecho a parar después de cualquier fase y llevarte todo lo construido hasta ese momento, incluidos el código, los prompts, el conjunto de aceptación y los scripts que puntúan el sistema con él. El artículo enlazado abajo explica cómo funciona la propiedad del código en un contrato.

¿Cómo comprobamos a una empresa que se ofrece a terminar nuestro piloto?

Escribe un brief de una página que diga qué hace el piloto, qué documentos lee y cuántos al día, adónde pueden ir los datos y qué puntuación necesitas. Envíalo a todas las empresas de tu lista corta con las mismas preguntas:

  • ¿Qué necesitan ver antes de poder fijar un precio, y para qué fase lo fijarían?
  • Muéstrennos cómo estaba estructurado un contrato anterior para un trabajo parecido, sin los precios ni el nombre del cliente
  • ¿Qué pasa si una prueba de aceptación falla al final de una fase?
  • ¿Quién de su equipo ha llevado un sistema de IA a producción, y trabajará esa persona en nuestro proyecto?
  • ¿Pueden sus ingenieros trabajar dentro de nuestro perímetro, con nuestras reglas de acceso?

El artículo sobre cómo externalizar el desarrollo de IA sin que tus datos salgan de la empresa, enlazado arriba, trata en detalle la última pregunta.

¿Qué debería ponernos en guardia en una propuesta?

  • Llega un precio para todo el trabajo antes de que la empresa haya visto un solo documento tuyo
  • La propuesta promete un porcentaje de respuestas correctas, pero no dice con qué documentos se medirá
  • Aparece la expresión «llave en mano» sin prueba de aceptación y sin derecho a parar entre fases
  • Faltan los costes de operación, o solo aparecen como «a convenir»
  • El borrador del contrato incluye los prompts o el conjunto de aceptación como propiedad de la empresa

¿Dónde encaja amBrain?

El único proyecto con modelos de lenguaje que amBrain describe en público es este: «Hemos llevado a producción una integración de LLM dentro del perímetro FinTech de un cliente: extracción y normalización de avisos no estructurados de brókers y de centros de negociación —eventos corporativos, cambios de instrumentos y de márgenes— en registros estructurados que consume el sistema de trading».

Este artículo no es un caso de estudio. No dice que el proyecto citado arriba empezara como el piloto atascado de otro equipo. Los modelos de pago descritos arriba, llave en mano y precio cerrado incluidos, son consejos generales, y el artículo no dice si amBrain ofrece alguno de ellos. No da precios ni plazos de amBrain.

amBrain se hace cargo de proyectos que se atascaron con otro equipo y los lleva a producción.

amBrain desarrolla software desde 2019. Sobre la propiedad, la frase de amBrain es: «El cliente conserva la propiedad completa del producto y del código, salvo nuestros componentes reutilizables». Pide a amBrain la lista de esos componentes nombre por nombre antes de firmar, como se la pedirías a cualquier otra empresa.

Si tu piloto se ha atascado, envía a amBrain el mismo brief y las mismas preguntas que envías a todas las demás empresas, y compara las respuestas una al lado de otra.

Preguntas frecuentes

  • Nuestro piloto ya tiene una cifra de precisión. ¿Por qué pagar por una evaluación? Si el piloto se probó con datos inventados o con documentos que alguien limpió a mano, su cifra dice poco de tus documentos reales. La evaluación mide el piloto con una muestra de ellos dentro de tu perímetro, y el borrador del conjunto de aceptación que produce es tuyo en cualquier caso
  • ¿Deberíamos contratar en su lugar nuestro propio equipo de ML? Si la IA es el producto que vendes, probablemente sí, y el artículo enlazado arriba sobre contratar un equipo de ML trata esa decisión. Si el sistema es una herramienta dentro de tus operaciones, una empresa puede terminar el piloto mientras tú contratas a las personas que lo operarán
  • ¿Tenemos que enseñar nuestros documentos a todas las empresas de la lista corta? No. El brief describe tus documentos sin incluirlos. Solo la empresa que elijas para la evaluación ve documentos reales, y trabaja dentro de tu perímetro

¿Tiene un diseño así sobre la mesa?

Traiga su arquitectura actual y el modo de fallo que le preocupa, y lo repasaremos juntos en media hora.