Cómo leer un acqui-hire antes de firmar: personas, propiedad intelectual o la empresa

Tu term sheet indica que el comprador puede hacer ofertas de empleo a personal seleccionado y obtener una licencia no exclusiva de propiedad intelectual. No dice que haya comprado la empresa. La documentación de Huxe-Apple muestra la diferencia de una forma que un fundador puede leer antes de firmar.

El expediente de Huxe es una operación de personas

Huxe comenzó en diciembre de 2024, cuando Raiza Martin, ex responsable del proyecto Google NotebookLM, se unió al diseñador Jason Spielman y al ingeniero Stephen Hughes. Abrió a usuarios por invitación en junio de 2025, se hizo pública en septiembre de 2025 y anunció $4,6 millones en financiación al mismo tiempo. Anunció su cierre en mayo de 2026 y dejó de servir a los usuarios el 28 de mayo de 2026.

Una divulgación de la UE del 9 de junio de 2026 otorgó a Apple derechos de oferta de empleo y contratación para personal seleccionado de Huxe AI y una licencia no exclusiva sobre su propiedad intelectual. Apple informó a la Comisión Europea que adquirió Huxe en junio por una cantidad no divulgada, en un acuerdo descrito como un acqui-hire. El expediente de la UE calificó la operación Huxe-Apple del 9 de junio como un acuerdo de contratación de personal y licencia de propiedad intelectual, no como una compra directa de la empresa.

Cuatro cláusulas deciden qué estás vendiendo

• Entidad frente a personas. Decide si el comprador adquiere participaciones o la empresa, o solo obtiene derechos de contratación. Cuando otorga derechos para hacer ofertas de empleo a personal seleccionado y una licencia, fija el precio del equipo, no de la empresa. El error habitual es valorar la empresa como si se comprara la entidad y luego descubrir que el comprador solo quiere a unas pocas personas.
• Propiedad intelectual exclusiva frente a no exclusiva. Responde quién posee el código, quién puede usarlo y quién puede impedir que otros lo usen. Una licencia no exclusiva permite a la plataforma usar el trabajo sin otorgarle control exclusivo. Sin exclusividad, no lo valores como si hubieras vendido la única copia.
• Datos de usuarios y obligaciones de servicio. Enumera qué se transfiere, qué se elimina y quién debe mantener el servicio funcionando durante cuánto tiempo. Mantener el producto operativo para la plataforma es una obligación de servicio, no solo una licencia.
• Dependencia del roadmap. Nombra las funciones de la plataforma en las que depende tu producto y la fecha en la que dejarías de operar si esas funciones cambian. Una dependencia fuerte convierte las cláusulas de personas en el centro de la operación.

Fijar el precio del equipo, no de la entidad

Empieza por el equipo que el comprador puede llevarse realmente. Cuando el documento solo otorga derechos de contratación para personal seleccionado, tu valoración debe construirse a partir de ofertas, bonificaciones y condiciones de retención, no de un múltiplo sobre ingresos. Un múltiplo de ingresos asume que la empresa sigue vendiendo. Una operación de personas paga por el equipo. Una hoja de cálculo útil tiene una fila por persona: oferta esperada, probabilidad de aceptación, bono de firma y la fecha en que la persona puede incorporarse. Cuando el comprador no puede forzar la contratación, la columna de probabilidad es la operación.

Mantén la entidad viva el tiempo suficiente para pagar al equipo. Un servicio que termina antes de que se acepten las ofertas puede dejar al equipo sin reclamación contra el comprador. Establece un plazo en el acuerdo para que el comprador haga las ofertas. El acuerdo debe indicar una fecha, una lista de personas elegibles y un disparador de pago si el comprador no cumple el plazo. Ese plazo es el reloj real de la operación.

En marzo, la FTC y el Departamento de Justicia comenzaron a examinar posibles actualizaciones de las normas de notificación premerger que capturarían operaciones centradas en la contratación y licencias no exclusivas de propiedad intelectual. La documentación importa, no solo el titular.

El riesgo de roadmap cambia el valor del equipo

Pregúntate qué hace el roadmap de la plataforma con tu producto. Cuando tu aplicación existe porque una gran plataforma expone un modelo, una API o un canal de distribución, la salida puede depender de que esa plataforma siga comportándose de la misma manera. Una breve nota debería listar las funciones de la plataforma en las que confías, las alternativas si cambian y la fecha en la que dejarías de desarrollar. Una nota vacía significa que estás valorando una dependencia que no has nombrado.

Incorpora el riesgo de roadmap en el valor del equipo. Una plataforma que puede cambiar las reglas hace que el valor de tu equipo sea mayor cuando puede moverse y menor cuando está atado a una sola plataforma. Mantén un camino independiente, aunque sea pequeño. Una exportación de datos, una nota de arquitectura que no dependa de un solo modelo y una lista de clientes que no se apoye en la plataforma son la prueba de que el equipo puede moverse.