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.
Seguir leyendo
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:
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.
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.
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:
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.
«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:
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.
Acuerda de antemano cómo cambian el precio estas situaciones:
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.
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.
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:
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.
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.
Traiga su arquitectura actual y el modo de fallo que le preocupa, y lo repasaremos juntos en media hora.