INNOVACION GLOBAL DE SEGURIDAD SA

Innovacion Global de Seguridad SA es una sociedad anónima española domiciliada en Madrid, constituida en el año 2012 y clasificada en el corpus como startup del sector de la seguridad. De acuerdo con la ficha registral consultada en OpenMercantil a partir del BORME, el estado registral de la sociedad es activo.

El corpus no aporta información sobre el objeto social detallado, el capital, la plantilla ni la facturación. Estos datos no constan.

La sociedad se constituyó en 2012, según la fecha de constitución recogida en el corpus. La información disponible no permite identificar a los socios fundadores ni las circunstancias de la constitución: los datos registrales que se proporcionan corresponden a actos de 2025 y 2026 y no incluyen la escritura de constitución.

El administrador único que consta es Juan José García García. En el corpus también aparecen como auditores inscritos Deloitte Auditores SL y Cervantes Auditores SLP, cargos que según el registro se renovaron en 2026.

El corpus solo indica que la sociedad pertenece al sector de la seguridad. No consta qué tipo de servicios o productos ofrecía, ni a qué tipo de clientes se dirigía, ni qué estructura territorial tenía más allá del domicilio en Madrid.

La designación de auditores (Deloitte Auditores SL y Cervantes Auditores SLP) consta en el BORME y es compatible con una sociedad sometida a auditoría de cuentas, pero el corpus no detalla la causa ni la dimensión.

El corpus no contiene datos financieros, comerciales ni de crecimiento de ningún ejercicio. No consta información sobre facturación, resultados, número de trabajadores o clientes en ningún periodo.

La única evolución documentada es registral: entre noviembre de 2025 y agosto de 2026 la sociedad inscribió un número elevado de nombramientos de apoderados, tanto individuales como solidarios, y la designación de auditores. Según el BORME, los nombramientos incluyen, entre otros, a 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 y Antonio Jesús Gómez Pérez. Esta actividad registral indica una estructura de apoderamientos amplia, pero el corpus no explica su finalidad.

No consta que la sociedad haya cerrado. De acuerdo con la ficha registral, el estado es activo y el último acto documentado es un nombramiento de apoderado inscrito en agosto de 2026. El corpus no contiene ningún indicio de disolución, concurso, venta o transformación societaria.

Dado que la sociedad consta activa, no se puede hablar de herencia en el sentido de cierre. El corpus no recoge ningún elemento de continuidad (marcas, filiales, activos traspasados) más allá de la propia sociedad.

El corpus no identifica a los fundadores de la sociedad. La única persona que consta como administrador único es Juan José García García, y el registro no indica si es fundador.

En cuanto a las personas que aparecen como apoderados, el corpus no dice nada de su situación actual más allá de los nombramientos inscritos. Para completar esta información habría que consultar la escritura de constitución y las cuentas depositadas en el Registro Mercantil de Madrid, así como las notas registrales actualizadas.

• En el sector de la seguridad, el apoderamiento amplio de cargos intermedios (como muestra la secuencia de nombramientos de 2025-2026) es un indicador de estructura operativa descentralizada; para evaluar su alcance hay que contrastarlo con las cuentas depositadas, que el corpus no incluye.
• La designación de auditores (Deloitte Auditores SL, Cervantes Auditores SLP) inscrita en el BORME es un dato verificable que permite situar a la empresa en el régimen de auditoría de cuentas; cualquier análisis de solvencia debería partir de estas cuentas y no de la información registral básica.
• La clasificación como "startup" en el corpus no se puede confirmar con las fuentes disponibles; en informes de este tipo hay que distinguir entre la categoría asignada y lo que acredita el registro.
• Un estado registral "activo" no equivale a actividad económica: la comprobación requiere depósito de cuentas y, si procede, datos de tráfico mercantil, que aquí no constan.

Reconstruir l'essència d'una empresa de seguretat privada madrilenya com a operador de seguretat integrada: vigilància i control d'accés (persones), sistemes electrònics i monitoratge (tecnologia), i consultoria de compliment normatiu i gestió de riscos (servei d'alt valor).

La dada registral més reveladora és l'estructura: una societat anònima amb auditors (Deloitte, Cervantes) i una xarxa molt àmplia d'apoderats nomenats en poc temps (2025-2026). Això és coherent amb una empresa que opera per delegació territorial i comercial —diversos apoderats amb capacitat de signar— i que ha de retre comptes formalment. És una pista sobre el model, no una prova del negoci.

Avui, la mateixa essència es pot construir més lleugera: menys estructura física, més plataforma tecnològica i subcontractació regulada.

El mercat de seguretat privada a Espanya és madur i regulat per la Llei 5/2014 de Seguretat Privada. Madrid concentra una part molt rellevant de la demanda: corporatiu, seus d'empreses, retail, esdeveniments i infraestructures.

Segments on una empresa nova pot entrar sense competir de front amb els grans operadors:

• Pimes i comerç de proximitat que volen control d'accés i videovigilància amb compliment legal, no només càmeres.
• Esdeveniments i espais temporals (demanda per pics, contracte curt).
• Compliment normatiu i auditories de seguretat per a empreses que han de justificar mesures davant assegurances o clients.
• Seguretat electrònica integrada amb monitoratge subcontractat a una central receptora aliena (alarma) — evita muntar infraestructura pròpia.

Nota: la mida i el creixement del mercat no es poden afirmar amb les fonts disponibles; caldria validar-ho amb dades sectorials (estimació a validar).

Model proposat (no verificat de l'original):

• Serveis recurrents (base estable): manteniment de sistemes, monitoratge, control d'accés gestionat. Contracte mensual.
• Projectes (marge puntual): instal·lació de sistemes, adequació normativa, auditories.
• Servei de personal (vigilància): el més regulat i el de marge més prim; es pot cobrir amb plantilla pròpia mínima i subcontractació a operadors habilitats.

Estructura de costos: alta proporció de cost variable (persones, subcontracted monitoring) i cost fix contingut (oficina, plataforma, assegurances i avals). El marge ve de la combinació de tecnologia + compliment, no del preu/hora de vigilància.

Requisits legals a tenir en compte des del dia u: habilitació com a empresa de seguretat, personal amb TIP, assegurança de responsabilitat civil i, sovint, aval. A validar amb el Ministeri de l'Interior abans de pressupostar.

Fases proposades (calendaris estimats):

1. Mesos 0-3 — Validació i habilitació. Confirmar nínxol (recomanat: pimes + compliment normatiu a Madrid), iniciar tràmits d'habilitació, tancar 3-5 clients pilots per carta d'intenció.
2. Mesos 3-6 — Operació mínima. Plataforma de gestió, acord amb central receptora i amb un operador de vigilància per subcontractar pics. Primers contractes recurrents.
3. Mesos 6-12 — Tracció comercial. Xarxa d'apoderats/comercials per delegació (replicant l'essència de l'estructura registral observada), 15-25 clients recurrents objectiu (estimació).
4. Mesos 12-24 — Escala i marge. Afegir consultoria i auditories, consolidar manteniment, avaluar plantilla pròpia de vigilància si el volum ho justifica.

Xifres estimades i a validar (rang orientatiu per a un operador lleuger a Madrid, primer any):

• Constitució, assessoria legal i habilitació: 8.000-20.000 € (l'aval i assegurances poden ser la part més gran; a validar).
• Plataforma de gestió i web: 10.000-30.000 €.
• Equipament inicial i estoc per a projectes: 15.000-40.000 €.
• Oficina i despeses d'estructura (12 mesos): 18.000-45.000 €.
• Màrqueting i desenvolupament comercial: 10.000-25.000 €.
• Capital de treball (3-6 mesos): 40.000-120.000 €.
• Assegurances i avals: variable, a validar (pot ser significatiu).

Total orientatiu: 150.000-400.000 € segons abast. El marge d'error és alt; cal pressupost real amb proveïdors i amb l'administració.

• Risc regulatori: la seguretat privada depèn d'habilitacions i del compliment estricte; un error de procediment pot aturar l'operació.
• Risc de marge en personal: la vigilància és intensiva en mà d'obra i molt competida; no és on construir el marge.
• Risc de concentració de clients: pocs contractes grans poden fer caure la facturació.
• Risc de dependència de tercers: central receptora i subcontractistes són crítics.
• Risc de lectura de les dades: les fonts només mostren estructura registral; no confirmen ingressos, clients ni viabilitat. Qualsevol pla que assumeixi mida o rendibilitat sense validar-ho és especulatiu.

Lliçons que es desprenen de l'informe original (estructura registral, no del negoci):

• La xarxa és l'actiu. La quantitat d'apoderats nomenats suggereix que el creixement depèn de delegació comercial i territorial, no d'un sol fundador. Qui ho refaci ha de construir xarxa des del dia u.
• El compliment formal és estructural. Auditors i societat anònima indiquen un negoci que ha de demostrar rigor; això és també un argument de venda davant clients.
• Cal capital per aguantar. Una empresa d'aquest sector no s'aguanta amb caixa just; el capital de treball és el risc número u.
• No confonguis estructura amb èxit. Les dades disponibles no diuen si el negoci funcionava; qui el reconstrueixi ha de validar mercat i marge abans d'invertir, no després.

Els actes del registre mostren una organització on la capacitat de signar s'ha distribuït en cascada: nomenaments d'apoderat solidari el 2025-12-22 i el 2026-05-07 (diversos noms en un sol acte), apoderats individuals el 2025-11-28 i el 2026-06-05, i un apoderat solidari únic el 2026-07-08 [BORME / BOE (via OpenMercantil), 2026-08-21]. Amb un administrador únic (GARCIA GARCIA JUAN JOSE) i dos auditors (DELOITTE AUDITORES SL, CERVANTES AUDITORES SLP), la pregunta operativa diària no és qui mana, sinó qui pot comprometre l'empresa en un contracte concret i quina combinació de signatures el fa vàlid.

Avui aquesta informació és al BORME, en PDF, en ordre cronològic i no en ordre de vigència. Un acte de 2026-05-07 que nomena set apoderats solidaris i un acte de 2026-06-05 que nomena quatre apoderats individuals no es poden creuar sense treball manual. El cost és triple: risc legal (signar amb poders caducats o insuficients), latència comercial (esperar validació jurídica per tancar un contracte) i risc de control intern (no poder demostrar a l'auditor que la signatura era vàlida en el moment de la signatura).

Tres serveis i un magatzem, deliberadament petits:

``` [BORME/BOE scraper] --(actes)--> [Ingestió + normalitzador] | v [Postgres: poders versionats] | +------------------+------------------+ v v [Motor de regles] [API de consulta] (mancomunitat, límits, (REST, read-heavy) vigència temporal) | ^ v | [Portal intern + SDK signatura] [Servei de validació de signatura] ```

Decisions i motius:

• Postgres amb taules bitemporals (`valid_from`/`valid_to` de negoci + `recorded_at` de sistema) en lloc d'un simple estat actual. Motiu: els poders es revoquen i es renomenen; l'auditor ha de poder preguntar "era vàlid el 3 de juny de 2026?" i obtenir la resposta d'aquell instant, no l'actual. Els actes de 2026-05-07 i 2026-06-05 són exactament el cas on l'ordre d'ingestió no coincideix amb l'ordre d'efectes.
• Motor de regles com a servei separat, no com a codi dins l'API. Motiu: les regles de mancomunitat canvien amb cada acte registral i han de poder-se versionar i testejar amb casos reals del BORME sense desplegar l'API.
• Ingestió semiautomàtica amb confirmació humana. Motiu: el text del BORME és estructuralment irregular (els actes barregen "Apo.Sol.", "apoderado", "apoderado_solidario" per al mateix fet). Un parser totalment automàtic generaria falsos positius en un domini on l'error té conseqüències legals. El sistema proposa, un jurista confirma.
• API de només lectura per al consum massiu (contractes, ERP, CRM) i escriptura restringida al flux d'ingestió. Motiu: la consulta de poders és de molta lectura i poca escriptura; separar-ho simplifica el càlcul de càrrega i el control d'accés.

Entitats principals (Postgres):

```sql -- Persona o entitat que pot tenir poders persona(id, nom_normalitzat, nom_borme, tipus) -- tipus: fisica | juridica

-- Acte registral tal com arriba de la font acte_registral( id, font_url, data_publicacio, num_borme, tipus_acte, -- nomenament | revocacio | cessament text_cru, -- literal del BORME checksum, ingerit_at )

-- El poder en si, versionat poder( id, persona_id, acte_id, classe, -- individual | solidari | mancomunat ambit, -- generic | per import | per matèria limit_import_eur, -- NULL = sense límit valid_from, valid_to, -- efectes de negoci recorded_at, -- bitemporal: quan ho vam saber estat -- proposat | confirmat | revocat )

-- Grups de mancomunitat: quants i qui cal per signar grup_signatura(id, poder_id, signatures_requerides, materia) membre_grup(grup_signatura_id, persona_id) ```

Per què així: `poder.classe` distingeix els tres règims que apareixen al BORME. Un apoderat solidari pot signar sol; un de mancomunat necessita el nombre de signatures del seu `grup_signatura`. Separar `grup_signatura` de `poder` permet que un mateix poder pertanyi a grups diferents segons la matèria (per exemple, dos signants per a contractes financers, un per a operacions corrents) sense duplicar el poder. `limit_import_eur` és nullable perquè la majoria d'apoderaments del BORME no fixen límit explícit; el motor ha de distingir "sense límit" de "límit zero".

API REST interna (v1):

• `GET /poders?persona={id}&data={ISO}` → poders vigents d'una persona en una data. Resposta inclou `classe`, `limit_import_eur` i, si és mancomunat, el `grup_signatura` amb els membres.
• `POST /validacio-signatura` → cos: `{ contracte_id, import, materia, signants: [persona_id...] }`. Retorna `{ valid: bool, motiu, signatures_faltants: [persona_id] }`. Aquest és l'endpoint que crida l'ERP en el moment de signar.
• `GET /actes?des_de={data}` → feed d'actes per a revisió humana.
• `POST /actes/{id}/confirmar` → converteix un acte proposat en poders confirmats (només rol `juridic`).

Integracions:

• Ingestió BORME/BOE: job diari que descarrega els PDFs del BORME de Madrid i extreu els actes de l'empresa per número de full registral (S 8, H M 534008). Font citada: [BOE / BORME, 2026-08-21].
• ERP / CRM: crida síncrona a `POST /validacio-signatura` abans de permetre l'enviament d'un contracte. Motiu: el punt de control ha de ser on es comet l'error, no en un informe posterior.
• Sistema de signatura electrònica: el SDK rep la llista de signants vàlids i bloqueja la recollida de signatures si el conjunt no compleix la regla de mancomunitat.

1. Normalitzador de noms + taula `persona`. Sense identitat unívoca de persones (GARCIA GARCIA JUAN JOSE apareix com a administrador únic i com a apoderat en actes diferents) res més funciona. És el coll d'ampolla real.
2. Ingestió manual assistida dels actes de 2025-11-28 a 2026-08-21. Carregar a mà els ~30 nomenaments verificats com a conjunt de proves daurat. Motiu: dona un corpus real per validar el parser abans d'automatitzar-lo.
3. Motor de regles de mancomunitat + `POST /validacio-signatura`. És el producte mínim que ja aporta valor: respondre "aquestes tres signatures són vàlides per a aquest contracte?".
4. Portal de consulta de poders per persona i data. Per a ús intern i auditoria.

No construir encara: alertes de caducitat, dashboard d'analítica, integració completa amb signatura electrònica. Arriben quan el motor de regles tingui casos reals.

Mides: ~40-50 persones amb poder actiu segons els actes; ~30 actes en nou mesos → ~120 actes/any. Volum de dades trivial (desenes de MB). El repte no és escala sinó qualitat d'extracció i correcció de regles.

Riscos:

• Ambigüitat del text BORME. El mateix acte apareix com "Apo.Sol." i com "apoderado_solidario" en registres duplicats (vegeu 2026-05-07 i 2026-06-05). Mitigació: deduplicació per `checksum` del text i per (persona, data_acte, tipus), amb revisió humana obligatòria.
• Ordre d'efectes vs. ordre de publicació. Un acte publicat el 2026-06-05 pot tenir efectes des del 2026-05-29 (data registral). Mitigació: model bitemporal; mai inferir vigència de la data de publicació.
• Poders sense límit explícit. Si el BORME no fixa import, el motor no pot assumir que és il·limitat per a totes les matèries. Mitigació: `limit_import_eur = NULL` es tracta com a "requereix confirmació jurídica" per a imports per sobre d'un llindar configurable, no com a permís.
• Dependència de la font. Si el BORME canvia de format o el scraper falla, el sistema queda desactualitzat en silenci. Mitigació: alerta si passen >7 dies sense cap acte nou detectat per a l'empresa, i marcatge visible de "darrera sincronització".

1. Conjunt daurat d'actes. Carregar els actes verificats de 2025-11-28 a 2026-08-21 [BORME / BOE, 2026-08-21] i comprovar que el parser proposa exactament els poders que un jurista confirma manualment. Mètrica: precisió i recall per persona i per classe de poder.
2. Tests de regles amb casos reals. Per a cada acte de nomenament múltiple (2025-12-22, 2026-05-07), un test que verifica que el motor retorna el nombre correcte de signatures requerides i els membres correctes del grup.
3. Tests bitemporals. Consultar `GET /poders?data=` per a dates entremig d'actes (p. ex. 2026-05-15, entre el nomenament del 2026-05-07 i el del 2026-06-05) i verificar que retorna l'estat vigent en aquell moment, no l'actual.
4. Prova de punta a punta amb l'ERP. Simular un contracte de 500 k€ signat per dos apoderats i verificar que `POST /validacio-signatura` retorna `valid: false` amb `signatures_faltants` si la regla de mancomunitat n'exigeix tres.

5