INNOVACION GLOBAL DE SEGURIDAD SA

Innovacion Global de Seguridad SA és una societat anònima espanyola domiciliada a Madrid, constituïda l'any 2012 i classificada al corpus com a startup del sector de la seguretat. D'acord amb la fitxa registral consultada a OpenMercantil a partir del BORME, l'estat registral de la societat és actiu.

El corpus no aporta informació sobre l'objecte social detallat, el capital, la plantilla ni la facturació. Aquestes dades no consten.

La societat es va constituir el 2012, segons la data de constitució recollida al corpus. La informació disponible no permet identificar els socis fundadors ni les circumstàncies de la constitució: les dades registrals que es proporcionen corresponen a actes de 2025 i 2026 i no inclouen l'escriptura de constitució.

L'administrador únic que consta és Juan José García García. Al corpus també apareixen com a auditors inscrits Deloitte Auditores SL i Cervantes Auditores SLP, càrrecs que d'acord amb el registre es van renovar el 2026.

El corpus només indica que la societat pertany al sector de la seguretat. No consta quina mena de serveis o productes oferia, ni a quin tipus de clients s'adreçava, ni quina estructura territorial tenia més enllà del domicili a Madrid.

La designació d'auditors (Deloitte Auditores SL i Cervantes Auditores SLP) consta al BORME i és compatible amb una societat sotmesa a auditoria de comptes, però el corpus no en detalla la causa ni la dimensió.

El corpus no conté dades financeres, comercials ni de creixement de cap exercici. No consta informació sobre facturació, resultats, nombre de treballadors o clients en cap període.

L'única evolució documentada és registral: entre el novembre de 2025 i l'agost de 2026 la societat va inscriure un nombre elevat de nomenaments d'apoderats, tant individuals com solidaris, i la designació d'auditors. Segons el BORME, els nomenaments inclouen, entre d'altres, Jaime Francisco Calzado Arija, Raquel Suárez Saiz, José Orosa Raja, José Luis Fortuny Badiola, Manuel Valero Ibáñez, Juan Manuel de Diego Sacristán, José Francisco Casal Eiras, Uriel Galindo Ballester, Cristina Prados Martín-Toral, José Antonio Gollonet Bautista, Miguel Ángel Delgado Rey i Antonio Jesús Gómez Pérez. Aquesta activitat registral indica una estructura d'apoderaments àmplia, però el corpus no n'explica la finalitat.

No consta que la societat hagi tancat. D'acord amb la fitxa registral, l'estat és actiu i l'últim acte documentat és un nomenament d'apoderat inscrit l'agost de 2026. El corpus no conté cap indici de dissolució, concurs, venda o transformació societària.

Atès que la societat consta activa, no es pot parlar d'herència en el sentit de tancament. El corpus no recull cap element de continuïtat (marques, filials, actius traspassats) més enllà de la pròpia societat.

El corpus no identifica els fundadors de la societat. L'única persona que hi consta com a administrador únic és Juan José García García, i el registre no indica si és fundador.

Quant a les persones que apareixen com a apoderats, el corpus no en diu res de la situació actual més enllà dels nomenaments inscrits. Per completar aquesta informació caldria consultar l'escriptura de constitució i les comptes dipositades al Registre Mercantil de Madrid, així com les notes registrals actualitzades.

• En el sector de la seguretat, l'apoderament ampli de càrrecs intermedis (com mostra la seqüència de nomenaments de 2025-2026) és un indicador d'estructura operativa descentralitzada; per avaluar-ne l'abast cal contrastar-ho amb les comptes dipositades, que el corpus no inclou.
• La designació d'auditors (Deloitte Auditores SL, Cervantes Auditores SLP) inscrita al BORME és una dada verificable que permet situar l'empresa en el règim d'auditoria de comptes; qualsevol anàlisi de solvència hauria de partir d'aquestes comptes i no de la informació registral bàsica.
• La classificació com a "startup" al corpus no es pot confirmar amb les fonts disponibles; en informes d'aquest tipus cal distingir entre la categoria assignada i el que acredita el registre.
• Un estat registral "actiu" no equival a activitat econòmica: la comprovació requereix dipòsit de comptes i, si escau, dades de tràfic mercantil, que aquí no consten.

El que es pot afirmar amb les fonts: existeix una societat anònima de seguretat, activa, amb una activitat registral intensa i recent (nombraments d'apoderats el 2025 i 2026, i auditoria de comptes per Deloitte). Aquesta densitat de nomenaments i la presència d'un auditor de gran firma suggereixen —això ja és interpretació, a validar— una estructura de grup o una societat amb volum suficient per requerir auditoria i una xarxa comercial àmplia representada per apoderats.

La proposta de reconstrucció "amb la mateixa essència" seria: una consultoria de seguretat integral que combini seguretat física (vigilància, control d'accés), seguretat electrònica (CCTV, alarmes, detecció) i consultoria de riscos, amb una capa de govern corporatiu sòlida des del dia u. No es proposa reconstruir una empresa de guàrdies de seguretat massiva (capital intensiu en personal i marge prim), sinó un model híbrid consultoria + tecnologia + servei.

El mercat de seguretat privada a Espanya és un sector regulat (Llei 5/2014 de Seguretat Privada) i madur, amb demanda estable en sectors com indústria, infraestructures, retail, esdeveniments i administració local. Navarra i la zona nord (País Basc, La Rioja, Aragó) tenen teixit industrial i agroindustrial que consumeix seguretat.

Advertiment: no disposo de dades verificades sobre la mida, quota o clients d'aquesta empresa concreta. Qualsevol xifra de mercat que donés seria una estimació externa no vinculada a la companyia. El que sí és verificable és que la societat continua activa i amb activitat registral el 2026, cosa que indica que el mercat on operava no ha desaparegut.

Proposta (no fet verificat). Tres línies:

1. Consultoria de riscos i auditories de seguretat — marge alt, poc capital, contractes per projecte i recurrència anual. És la porta d'entrada comercial.
2. Integració de sistemes de seguretat electrònica — instal·lació i manteniment de CCTV, control d'accés i detecció. Ingressos recurrents via manteniment.
3. Servei de vigilància subcontractat o propi — només un cop la cartera de clients justifiqui l'escala; és la línia de marge més baix i més intensiva en compliment normatiu (habilitacions, conveni col·lectiu).

El tret diferencial que la dada registral sí suggereix: govern corporatiu i transparència comptable des del primer dia (auditoria externa), cosa que facilita licitacions públiques i contractes amb grans comptes.

Proposta, en quatre fases:

• Fase 0 (mesos 0-3): constitució, habilitació com a empresa de seguretat privada si es vol fer vigilància (requereix autorització administrativa), i definició de l'oferta de consultoria.
• Fase 1 (mesos 3-9): captació de 5-10 clients de consultoria i auditoria a Navarra i nord. Sense plantilla de vigilància.
• Fase 2 (mesos 9-18): primera línia d'integració electrònica amb un soci tecnològic o distribuïdor; contractes de manteniment.
• Fase 3 (mesos 18-36): valorar servei de vigilància propi o aliança amb una empresa ja habilitada, i obrir licitacions públiques.

Tot són estimacions a validar, no dades de l'empresa original.

• Constitució, assessoria i estructura mínima: rang de 3.000-8.000 €.
• Habilitació administrativa com a empresa de seguretat (si s'opta per vigilància): cost i termini a validar amb el Ministeri de l'Interior; pot ser de mesos.
• Equip fundador mínim (2-3 persones, 12 mesos): rang de 90.000-180.000 € en sous i càrregues.
• Estoc i equip de demostració per a integració electrònica: rang de 10.000-30.000 €.
• Màrqueting, web, CRM i eines: rang de 6.000-15.000 € el primer any.
• Capital circulant per cobrir desfasaments de cobrament (típics en contractes públics i industrials): rang de 30.000-60.000 €.

Total orientatiu per arrencar sense línia de vigilància: rang de 140.000-290.000 €, a validar amb un pla financer real. Amb vigilància pròpia, la xifra puja substancialment per nòmines i assegurances.

• Regulació: la seguretat privada és sector habilitat; operar sense autorització és il·legal. Risc alt si es vol fer vigilància.
• Marge prim en serveis de personal: el conveni col·lectiu i la competència per preu comprimeixen marges.
• Concentració de clients: en consultoria, perdre un compte gran pot trencar el pla.
• Desfasament de cobrament: especialment amb administracions públiques.
• Risc de reputació i responsabilitat civil: cal assegurança adequada.
• Risc d'informació: no tenim dades verificades de per què la companyia original va cessar l'activitat operativa (si ho va fer); reconstruir sense entendre la causa és el risc número u.

Les lliçons que es poden extreure de l'expedient original, més enllà de la reconstrucció:

1. El govern corporatiu no és un luxe tardà: l'empresa original va arribar a tenir auditoria de Deloitte i desenes d'apoderats. Això indica que la formalització i el control comptable es van prendre seriosament — i és el que cal replicar des del dia u, no quan l'empresa ja és gran.
2. Una xarxa àmplia d'apoderats és una eina comercial, però també un risc de govern: cal definir límits clars d'actuació per apoderat.
3. L'administrador únic concentra responsabilitat: en una reconstrucció, convé un consell o almenys un soci tècnic i un de comercial.
4. La seu registral i la seu operativa poden divergir: la fitxa vincula l'empresa a Navarra però el registre és a Madrid; en un nou projecte, cal decidir on és el centre operatiu real i on el fiscal.
5. Qui ho hauria de fer: un equip amb experiència operativa real en seguretat (no només financera), un soci comercial amb cartera al nord d'Espanya, i un assessor legal especialitzat en seguretat privada. La solidesa comptable de l'original és el model a imitar; la resta, a construir amb dades pròpies.

La cronologia registral de la companyia (font: [BORME / BOE via OpenMercantil, 2026-08-21]) mostra un ritme de nomenaments molt alt: el 2026-05-07 es nomenen set apoderats solidaris en un sol acte, el 2026-06-05 quatre apoderats més, el 2026-07-08 un apoderat i el 2026-08-20/21 un apoderat solidari. En total, més de vint persones amb capacitat de representació en menys de quatre mesos, sense cap acte de revocació visible a la mostra.

Això genera tres problemes reals en una empresa de seguretat:

1. Risc de signatura no autoritzada o caducada. Ningú no té una vista única de qui pot signar avui, amb quin abast (solidari vs. mancomunat) i des de quina data.
2. Fricció en licitacions i contractació pública. Els plecs exigeixen acreditar poders vigents; reconstruir-ho a partir de PDFs del BORME és lent i propens a error.
3. Auditoria i compliance. Amb dos auditors actius (Deloitte i Cervantes segons els actes de 2026-05-07), cal un rastre immutable de canvis de poders per a l'informe d'auditoria.

El producte no és un gestor documental: és un motor de vigència de poders amb API de verificació.

Arquitectura en tres capes, deliberadament simple perquè el valor és la correcció del model de vigència, no la infraestructura.

``` [Ingesta] [Nucli] [Consum] BORME/BOE PDF --> Normalitzador d'actes --> API de verificació CSV registral Motor de vigència Portal intern Webhook notarial (event sourcing) Export auditoria ```

Decisions i motius:

• Event sourcing sobre els actes registrals. Cada acte BORME és un esdeveniment immutable (`Nomenament`, `Revocació`, `Dimissió`, `Cessament`). Motiu: la vigència d'un poder és una funció del conjunt d'esdeveniments, i l'auditoria exigeix poder reconstruir l'estat en qualsevol data passada. Un model CRUD sobre "apoderats" perdria la història que l'auditor necessita.
• Projecció de lectura materialitzada (`poder_viu`) recalculada per cada esdeveniment. Motiu: les consultes de verificació han de ser de mil·lisegons i no poden recórrer la cadena d'esdeveniments.
• Ingesta amb revisió humana obligatòria (human-in-the-loop). Motiu: l'extracció de PDFs del BORME té errors (noms compostos, abreviatures `Apo.Sol.`), i un fals positiu de poder és pitjor que un fals negatiu. Cap acte passa a "confirmat" sense validació.
• PostgreSQL + `tstzrange` per a intervals de vigència. Motiu: permet consultes de solapament i de "poder vàlid en data X" amb índexs GiST natius, sense inventar lògica temporal a l'aplicació.

Esquema relacional amb taula d'esdeveniments i projecció.

```sql -- Esdeveniments registrals crus CREATE TABLE acte_registral ( id uuid PRIMARY KEY, empresa_cif text NOT NULL, data_acte date NOT NULL, tipus text NOT NULL CHECK (tipus IN ('nomenament','revocacio','dimissio','cessament','auditor')), font_url text NOT NULL, -- p.ex. PDF BORME font_ref text NOT NULL, -- "S 8, H M 534008, I/A 41" payload_json jsonb NOT NULL, -- text cru extret estat text NOT NULL DEFAULT 'pendent' CHECK (estat IN ('pendent','confirmat','rebutjat')), confirmat_per text, confirmat_el timestamptz );

-- Persona (apoderat, administrador, auditor) CREATE TABLE persona ( id uuid PRIMARY KEY, nom text NOT NULL, nif text UNIQUE );

-- Assignació de poder derivada d'un acte confirmat CREATE TABLE poder ( id uuid PRIMARY KEY, persona_id uuid REFERENCES persona(id), acte_origen uuid REFERENCES acte_registral(id), tipus text NOT NULL CHECK (tipus IN ('solidari','mancomunat','administrador_unic','auditor')), abast text[] NOT NULL, -- àmbits: contractacio, banc, licitacio vigencia tstzrange NOT NULL, -- [inici, fi) ; fi NULL = vigent revocat_per uuid REFERENCES acte_registral(id) ); CREATE INDEX poder_vigencia_gist ON poder USING gist (vigencia); ```

La projecció `poder_viu` és una vista materialitzada que filtra `vigencia @> now()` i `revocat_per IS NULL`. El camp `abast` és una decisió explícita: un apoderat solidari per a contractació no equival a un per a operacions bancàries, i el model ho ha de poder distingir encara que el BORME no ho detalli (s'omple manualment en confirmar).

API REST, autenticada amb OAuth2 (client credentials per a sistemes, OIDC per a usuaris interns).

Endpoints principals:

• `POST /v1/actes` — ingesta d'un acte cru (estat `pendent`). Idempotent per `(font_ref, data_acte)`.
• `POST /v1/actes/{id}/confirmar` — valida i genera la projecció `poder`.
• `GET /v1/poders?vigent=true&abast=contractacio` — llista de poders vigents.
• `GET /v1/verificar?persona_nif=...&data=2026-08-21&abast=licitacio` — resposta binària + justificació:

```json { "autoritzat": true, "poder_id": "...", "acte_origen": "BORME-A-2026-161-28", "vigencia": "[2026-08-14, )", "abast": ["contractacio","licitacio"] } ```

• `GET /v1/auditoria/export?des_de=...&fins_a=...` — CSV signat per a l'auditor.

Integracions:

• OpenMercantil / BORME: connector de sondeig diari que descarrega els PDFs del BORME de Madrid i els encua a la cua d'ingesta. Motiu: és la font primària citada i no depèn de cap proveïdor de pagament.
• ERP / signatura electrònica: webhook `poder.revocat` perquè el sistema de signatura desactivi credencials automàticament en detectar una revocació confirmada.
• Registre Mercantil (futur): el camp `font_ref` ja està dissenyat per encaixar amb l'API de certificacions quan estigui disponible.

Ordre deliberat, cada pas desbloqueja el següent:

1. Model d'esdeveniments + ingesta manual assistida. Carregar a mà els actes de la cronologia coneguda (2025-11-28 a 2026-08-21) per validar el model de vigència amb dades reals abans d'automatitzar res.
2. Motor de vigència i endpoint `/verificar`. És el nucli de valor; sense això no hi ha producte.
3. Connector BORME + cua de revisió humana. Automatitza la ingesta però manté el control.
4. Export d'auditoria signat. Requisit perquè l'auditor (Deloitte/Cervantes) accepti el sistema com a font.
5. Webhook de revocació cap a signatura electrònica. Tanca el bucle operatiu.

No construir abans del punt 3: cap UI elaborada ni multi-empresa. El risc principal és modelar malament la vigència, i això es descobreix amb dades reals, no amb pantalles.

• Volum: baix. La companyia genera desenes d'actes l'any; el sistema ha de suportar milers d'empreses si s'escala a producte, però per a un sol client n'hi ha prou amb PostgreSQL estàndard.
• Risc 1 — Extracció de PDF del BORME. Els noms compostos i les abreviatures (`Apo.Sol.`, `apoderado_solidario`) generen ambigüitat. Mitigació: revisió humana obligatòria i tests de regressió amb els PDFs reals citats.
• Risc 2 — Abast del poder no explicitat al BORME. El registre diu qui i des de quan, però no per a què. Mitigació: camp `abast` omplert en confirmació; el sistema ha de fallar tancat (denegar) si l'abast no està definit.
• Risc 3 — Latència de publicació del BORME. Un nomenament pot trigar dies a publicar-se. Mitigació: el sistema no pretén ser en temps real; documenta la data d'acte, no la de publicació, i exposa `font_ref` perquè l'usuari verifiqui.
• Risc 4 — Confiança legal. Un sistema intern no substitueix una certificació registral. Mitigació: cada resposta de `/verificar` inclou la referència a l'acte font; el sistema és un accelerador, no una font de dret.

• Test de reconstrucció històrica: donada la cronologia real (font: [BORME / BOE via OpenMercantil, 2026-08-21]), el motor ha de respondre correctament "quants poders vigents hi havia el 2026-06-01" i coincidir amb el recompte manual dels actes.
• Test de revocació: introduir un acte de revocació simulat i verificar que `/verificar` passa a `false` i que el webhook s'emet.
• Test de fallada tancada: consulta amb `abast` no definit → `autoritzat: false` amb motiu explícit.
• Validació amb auditor: l'export d'auditoria ha de ser acceptat per un auditor extern com a rastre suficient; es prova amb un cas real abans de tancar el punt 4.
• Mètrica d'operació: temps mitjà de confirmació d'un acte (objectiu < 2 min) i percentatge d'actes que requereixen correcció manual (objectiu < 15%).