Weroi

WEROI DIGITAL SOCIEDAD LIMITADA, conocida comercialmente como Weroi, era una sociedad limitada constituida en el año 2020 y ubicada en Bizkaia. Según los datos disponibles, operaba en el sector del software y el SaaS (programario como servicio). Su actividad se desarrolló durante seis años, hasta el cierre en 2026.

La sociedad se constituyó en el año 2020 en Bizkaia. No consta en el corpus facilitado la identidad de los fundadores ni las circunstancias concretas de la constitución. De acuerdo con el registro, la sociedad nombró auditor en los años 2022 y 2023: el 13 de enero de 2022 y el 19 de enero de 2023, con A.B.Z. AUDILAN SOCIEDAD LIMITADA PROFESIONAL como auditora en ambos casos, según consta en el BORME.

Weroi operaba en el sector del software y el SaaS, de acuerdo con la clasificación sectorial de los datos disponibles. El corpus facilitado no detalla qué producto concreto ofrecía, qué nicho de mercado cubría ni qué clientes tenía. Esta información no consta.

El corpus no aporta datos de facturación, número de clientes, financiación captada ni crecimiento. El único elemento que consta es el nombramiento de auditor en los ejercicios 2022 y 2023, según el BORME, lo que indica que la sociedad sometió sus cuentas a auditoría en aquellos ejercicios. No se puede afirmar nada más sobre la evolución del negocio durante los años de actividad.

Según el diario Gananzia (26 de enero de 2026), Weroi fue la primera empresa vasca que cerró como consecuencia de la IA generativa. Esta es la causa de cierre verificada que consta en el corpus. El registro recoge el cierre con fecha 26 de enero de 2026, y la ficha registral y el acto del BORME son del 20 de enero de 2026. El corpus no detalla cómo se concretó este impacto de la IA generativa sobre el producto o el modelo de negocio de Weroi; esta información no consta.

El corpus no recoge información sobre activos, propiedad intelectual, clientes o equipo que hayan sido traspasados o que hayan continuado de otra manera. Esta información no consta. El elemento que sí recoge la fuente es el carácter de precedente: según Gananzia, Weroi fue la primera empresa vasca que cerró como consecuencia de la IA generativa.

El corpus facilitado no identifica los fundadores ni socios de WEROI DIGITAL SOCIEDAD LIMITADA, ni indica cuál es su situación actual. Esta información no consta. Para trazarla se podrían consultar los datos de socios y administradores en la ficha registral de OpenMercantil y en los actos del BORME de constitución y posteriores, así como las notas de auditoría depositadas en el Registro Mercantil de Bizkaia.

• En SaaS, la irrupción de una capacidad nueva como la IA generativa puede afectar el núcleo del producto; las empresas del sector deberían hacer un seguimiento explícito de cómo evoluciona la tecnología que sostiene su propuesta de valor, no solo la de los competidores.
• La fuente sitúa a Weroi como el primer caso documentado en Euskadi de cierre por esta causa; conviene tratarlo como una señal a observar y no como una tendencia consolidada, dado que el corpus solo recoge este caso.
• Disponer de auditoría en los ejercicios 2022 y 2023 indica un cierto grado de formalización contable; esto no evitó el cierre, lo que recuerda que el control financiero no sustituye la vigilancia sobre el producto y el mercado.
• Para estudios posteriores, habría que documentar la composición del equipo fundador y los datos de facturación, que en este corpus no constan, para poder analizar con más precisión cómo el impacto tecnológico se traduce en el cierre.

No sabem, amb les dades verificades disponibles, quin producte concret feia Weroi. El que sí que sabem és el seu perfil: una societat limitada constituïda el 2020 a Bizkaia, sector software i SaaS, que va arribar a nomenar auditor els exercicis 2022 i 2023 (senyal d'una estructura comptable formalitzada, no d'un projecte improvisat) i que va tancar el gener de 2026. La causa verificada del tancament és la IA generativa.

La idea que es proposa avui no és "refer el mateix producte", sinó construir un SaaS que tracti la IA generativa com a infraestructura pròpia i no com a amenaça externa. Concretament, una eina vertical per a un nínxol concret (a validar) on el valor no estigui en la funcionalitat bruta —que la IA generativa commodititza— sinó en la integració, les dades propietàries del client, el compliment normatiu i la confiança operativa.

La lliçó del tancament de Weroi, tal com la recull la font de premsa, és que un SaaS genèric pot ser substituït per un model generatiu en mesos. La reconstrucció ha de partir d'aquesta premissa, no ignorar-la.

El mercat rellevant no és "software i SaaS" en abstracte: és el nínxol vertical on una empresa petita de Bizkaia pot tenir accés real a clients. Amb les dades verificades no podem afirmar quants clients tenia Weroi ni quin nínxol servia, i per tant no podem dimensionar el seu mercat original.

El que sí que podem afirmar és que el mercat del SaaS genèric s'ha comprimit per l'efecte de la IA generativa: eines que abans requerien un producte dedicat ara es resolen amb un assistent generatiu integrat en plataformes existents. Això empeny les empreses noves cap a nínxols on la IA generativa és un component, no un substitut: sectors regulats, dades sensibles, fluxos de treball complexos, integracions amb sistemes antics.

Com a proposta (a validar): un nínxol vertical B2B a Euskadi i a l'Estat, amb clients d'entre 20 i 200 treballadors, on la despesa en programari sigui recurrent i on la substitució per un xatbot genèric sigui poc probable per raons de compliment o de integració. La mida d'aquest mercat és una estimació que caldria contrastar amb dades d'associacions sectorials i amb entrevistes a potencials clients.

Proposta, no fet verificat: subscripció SaaS per seient o per volum d'operacions, amb un component d'implantació inicial (onboarding, integració amb sistemes del client) que financiï els primers mesos i que creï cost de canvi.

Tres decisions de disseny que la reconstrucció hauria de prendre des del primer dia:

• La IA generativa és dins del producte, no al costat. El client no hauria de poder dir "això ho faig millor amb ChatGPT": el producte ha d'incorporar el model generatiu com a capa, amb les dades del client i les regles del seu sector.
• Dades propietàries o d'integració com a fossat. El valor ha de venir de l'accés a dades o sistemes que un model genèric no té.
• Preu lligat a resultat operatiu, no a funcionalitats. Si el producte s'assembla a una llista de features, és substituïble.

Els ingressos recurrents haurien de ser la majoria de la facturació a partir del segon any; la proporció exacta és una estimació a validar amb el pla financer.

Proposta en quatre fases, amb terminis estimats:

1. Mesos 0-2 — Validació del nínxol. Entrevistes amb 20-30 potencials clients d'un sol vertical. Objectiu: confirmar que el problema existeix, que es paga per resoldre'l i que la IA generativa genèrica no el resol avui. Cost estimat: temps fundador, cap despesa rellevant.
2. Mesos 2-5 — Prototip amb un client pilot. Un sol client, un sol flux de treball, integració real. L'objectiu no és vendre, és aprendre on la IA generativa falla i on el producte guanya.
3. Mesos 5-9 — Producte mínim venible i primers 5-10 clients de pagament. Preus d'entrada baixos (estimació: 200-800 €/mes per client, a validar segons el vertical).
4. Mesos 9-18 — Repetició del model de venda i primeres contractacions. Un perfil comercial i un perfil tècnic, com a mínim.

La seqüència és deliberadament lenta al principi: la causa del tancament de Weroi suggereix que anar ràpid cap a un producte genèric és el camí més curt a la irrelevància.

Totes les xifres són estimacions a validar, no dades de Weroi:

• Cost de constitució i estructura legal: 1.000-3.000 € (societat limitada, gestoria, comptabilitat inicial).
• Cost d'infraestructura tècnica els primers 12 mesos: 3.000-10.000 € (serveis cloud, APIs de models generatius, eines de desenvolupament). El cost d'API generativa pot variar molt segons el volum i el model triat.
• Cost d'equip fundador els primers 12 mesos: depèn de si hi ha sou o no. Si hi ha dos fundadors a temps complet amb sou modest, estimació de 60.000-100.000 € anuals; si no n'hi ha, zero en caixa però cost d'oportunitat.
• Cost comercial i de màrqueting inicial: 5.000-15.000 € el primer any.
• Total orientatiu per als primers 12 mesos: entre 70.000 € i 130.000 € si hi ha sou fundador, i entre 10.000 € i 30.000 € si no n'hi ha. A validar amb un pla financer detallat.

Aquestes xifres no inclouen finançament extern ni subvencions, que a Euskadi podrien reduir la necessitat de caixa (a explorar, no verificat en aquest informe).

• El risc que va matar Weroi segueix existint. La IA generativa no s'atura; un producte que avui no és substituïble pot ser-ho en 18 mesos. La mitigació és el fossat de dades i integració, no la funcionalitat.
• Risc de nínxol massa petit. Un vertical molt específic pot donar tracció ràpida però sostre baix. Cal validar la mida abans de comprometre-hi el producte.
• Risc de dependència de proveïdors de models. Si el producte es recolza en una API externa, els canvis de preu o de política del proveïdor afecten directament el marge.
• Risc de credibilitat. Una empresa que reconstrueix sobre les cendres d'una altra pot tenir dificultats per captar socis o finançament si no es presenta com una empresa nova, amb nom i equip propis.
• Risc de memòria del mercat. A Bizkaia, el tancament de Weroi és un fet públic (font de premsa); això pot ser un actiu narratiu o un passiu, segons com es gestioni.

Les lliçons de l'informe original, més que un currículum:

• Un equip que accepti que la IA generativa és el terreny de joc, no una amenaça a gestionar. Weroi va tancar per la IA generativa; la reconstrucció ha de néixer amb aquesta premissa incorporada al producte des del primer dia.
• Algú amb accés real a un nínxol vertical. No un fundador genèric de SaaS, sinó algú que conegui de dins el sector al qual ven.
• Un equip petit i disciplinat en caixa. Sis anys d'activitat i auditoria nomenada suggereixen una estructura formalitzada; la reconstrucció hauria de començar més lleugera i créixer només amb tracció verificada.
• Capacitat de dir no al producte genèric. La temptació de fer "un SaaS més" és el camí que ja va portar al tancament.
• Un relat honest del que va passar. Explicar el tancament de Weroi com a aprenentatge, no amagar-lo, és més creïble que presentar-se com si res no hagués passat.

Aquest informe no reconstrueix Weroi: proposa una empresa nova que n'hereta el context i n'evita l'error. Totes les xifres i els nínxols concrets són estimacions a validar abans de comprometre-hi capital.

Quan un proveïdor SaaS tanca, els seus clients no perden només una eina: perden el significat de les seves dades. Els exports (CSV, JSON, dumps de base de dades) existeixen, però les regles de negoci que donaven sentit a aquestes dades —camps calculats, validacions, fluxos d'aprovació, estats— viuen al codi del proveïdor i desapareixen amb ell. El cas de Weroi és explícit: el tancament es va produir "com a conseqüència de la IA generativa" [Gananzia, 2026-01-26], i la fitxa registral confirma la dissolució [BORME / BOE (via OpenMercantil), 2026-01-20].

La IA generativa no resol aquest problema perquè no pot garantir determinisme, auditabilitat ni reproduïbilitat sobre dades de negoci. Un client que necessita que la facturació quadri al cèntim no pot dependre d'un model probabilístic. El producte que proposo ocupa exactament aquest buit: reconstrucció assistida i execució determinista de la lògica de negoci perduda, amb la IA generativa com a eina d'acceleració de la migració, no com a motor d'execució.

Tres capes, amb una frontera dura entre elles:

``` [ Exports del proveïdor difunt ] [ Documentació / contractes ] | | v v +--------------------------------------------------+ | CAPA 1: Ingesta i inferència d'esquema | | - Connectors d'import (CSV, JSON, SQL dump) | | - Perfilat estadístic de columnes | | - Propostes d'esquema (assistides per LLM, | | sempre revisables per humà) | +--------------------------------------------------+ | v +--------------------------------------------------+ | CAPA 2: Nucli de domini versionat | | - Entitats, camps, tipus, invariants | | - Regles de negoci en DSL declaratiu | | - Versionat immutable (cada canvi = commit) | +--------------------------------------------------+ | v +--------------------------------------------------+ | CAPA 3: Motor d'execució determinista | | - Avaluador del DSL (sense LLM en runtime) | | - API REST + webhooks | | - Registre d'auditoria append-only | +--------------------------------------------------+ ```

Motiu de la separació: la capa 1 pot ser probabilística i equivocar-se, perquè el seu output és una proposta que un humà aprova. La capa 3 ha de ser totalment determinista perquè el seu output són dades de negoci. Barrejar-les seria el mateix error que va matar el model de negoci anterior: dependre d'un component opac per a una funció crítica.

Per què un DSL declaratiu i no codi generat: el codi generat per LLM no és auditable ni estable entre versions. Un DSL restringit (condicions, càlculs, transicions d'estat) es pot validar, testejar i versionar. L'LLM ajuda a traduir documentació a DSL, però el DSL s'executa sol.

Cinc entitats principals, totes amb `tenant_id` i timestamps:

• `tenant`: organització client. Camps: `id`, `nom`, `pla`, `data_alta`.
• `schema_version`: snapshot immutable de l'esquema d'un tenant. Camps: `id`, `tenant_id`, `versio` (enter), `definicio` (JSONB), `origen` (enum: `import`, `manual`, `inferit`), `aprovat_per`, `created_at`. Cap `schema_version` es modifica; se'n crea una de nova.
• `entity_def` i `field_def`: dins del JSONB de `schema_version`, però també materialitzats en taules per a consultes ràpides. `field_def` inclou `tipus`, `nullable`, `invariants` (llista de predicats DSL).
• `rule`: regla de negoci. Camps: `id`, `tenant_id`, `schema_version_id`, `nom`, `trigger` (enum: `on_create`, `on_update`, `on_schedule`), `condicio` (DSL), `accio` (DSL), `activa`.
• `record`: dada de negoci. Camps: `id`, `tenant_id`, `entity`, `schema_version_id`, `payload` (JSONB), `created_at`, `updated_at`. El `payload` es valida contra l'esquema de la versió indicada.
• `audit_log`: append-only. Camps: `id`, `tenant_id`, `actor`, `accio`, `abans` (JSONB), `despres` (JSONB), `ts`.

Motiu del versionat d'esquema: els clients que migren tenen dades històriques que no compleixen l'esquema nou. Cal poder llegir dades antigues amb l'esquema amb què es van crear, i migrar-les explícitament. Un esquema mutable in situ faria illegibles les dades antigues.

• `POST /v1/imports`: puja un fitxer d'export. Retorna `import_id`. Asíncron; el client consulta `GET /v1/imports/{id}` per l'estat (`perfilant`, `proposant_esquema`, `pendent_aprovacio`, `completat`).
• `GET /v1/schemas/{tenant}/proposta`: retorna la proposta d'esquema inferida, amb un `confidence` per camp. L'humà l'aprova via `POST /v1/schemas/{tenant}/aprovar`.
• `POST /v1/records` i `PATCH /v1/records/{id}`: executen les regles `on_create`/`on_update` de forma síncrona i retornen el resultat o l'error de validació amb el predicat que ha fallat.
• `POST /v1/rules`: crea una regla en DSL. El DSL es valida sintàcticament i semànticament abans de desar-se.
• Webhooks: `record.created`, `record.updated`, `rule.failed`. Signats amb HMAC-SHA256.
• Integració amb IA generativa: només a la capa 1, via un servei intern `schema-infer` que crida un LLM amb el perfil estadístic de les columnes i la documentació pujada. El resultat es desa com a `proposta`, mai s'aplica directament. Això permet canviar de model o de proveïdor sense tocar el nucli.

Motiu de l'asincronia a la importació: els exports poden ser de gigabytes; un endpoint síncron faria timeouts i bloquejaria el client.

1. Importador de CSV/JSON amb perfilat estadístic (sense LLM). És la peça que demostra valor immediat: el client veu les seves dades llegides i perfilades en minuts.
2. Motor de DSL i validador d'esquema, amb un conjunt mínim de predicats (comparació, pertinença, suma, dates). Sense això no hi ha producte, només un visualitzador de dades.
3. `audit_log` i versionat d'esquema des del primer dia. Retrofitjar-ho després és inviable.
4. La capa d'inferència amb LLM, en últim lloc. És l'accelerador, no el producte. Si es construeix primer, el producte sembla una demo i no un sistema.

Motiu de l'ordre: cada pas ha de ser útil per si sol. Un client pot començar a operar amb l'importador i regles escrites a mà; la inferència assistida li estalvia feina, però no és un requisit per funcionar.

• Mida del mercat: nínxol. Cada tancament de proveïdor SaaS genera un grapat de clients orfes; el producte no és massiu. Cal dimensionar l'equip per a desenes de tenants, no milers. Un sol enginyer de backend i un de dades poden sostenir la v1.
• Risc 1 — el DSL es queda curt. Cada client té regles que no encaixen al DSL. Mitigació: permetre "escapatòria" a funcions registrades en codi, versionades i auditades, però amb revisió obligatòria.
• Risc 2 — la inferència d'esquema falla i el client no se'n refia. Mitigació: la proposta sempre és revisable i el client pot escriure l'esquema a mà. La confiança per camp és visible.
• Risc 3 — responsabilitat legal sobre dades reconstruïdes. Si una regla reconstruïda calcula malament un impost, qui respon? Mitigació: termes que deixen clar que el client aprova cada regla, i `audit_log` que registra qui va aprovar què i quan.
• Risc 4 — el proveïdor difunt reclama propietat intel·lectual de la lògica. Mitigació: el producte no copia codi; reconstrueix comportament a partir de dades i documentació del client. Cal assessorament legal, però l'arquitectura ja ho afavoreix.

• Test de reconstrucció: agafar un export real (o sintètic) d'un SaaS tancat, reconstruir-ne l'esquema i les regles, i verificar que els càlculs coincideixen amb els resultats històrics coneguts. Criteri d'èxit: 100% de coincidència en camps calculats sobre una mostra de 10.000 registres.
• Test de determinisme: executar el mateix conjunt de regles sobre el mateix `payload` 1.000 vegades i comprovar que el resultat és idèntic bit a bit. Cap crida a LLM en aquest camí.
• Test d'auditoria: cada mutació de `record` ha de generar exactament una entrada a `audit_log`; verificar-ho amb un test d'integració que intenta mutacions concurrents.
• Validació amb usuaris: un pilot amb un client real que hagi patit el tancament d'un proveïdor (no necessàriament Weroi, que ja és tancada [BORME / BOE, 2026-01-20]). Criteri: el client pot operar durant 30 dies amb el producte sense el proveïdor original.
• Validació del discurs: el producte no ha de vendre's com "IA que reconstrueix el teu SaaS", sinó com "continuïtat determinista amb assistència d'IA". Si el pilot no distingeix les dues coses, el posicionament ha fracassat.