---
id: SI_009
model: anthropic/claude-opus-4.6
seeds:
  04_risiko: sårbarhet
  03_relasjon: samarbeid
  05_handling: implementer
  01_perspektiv: juridisk
  02_tidhorisont: langsiktig
---

# Instans SI_009
**Seeds:** juridisk | langsiktig | samarbeid | sårbarhet | implementer

## Juridisk fundament først — alt annet kollapser uten

Den største sårbarheten i denne visjonen er ikke teknisk, men juridisk. Du bygger en profileringsmotor mot organisasjoner. Det krever et bevisst rettslig grunnlag fra dag én.

**Konkret håndtering:** Offentlige registre (Brønnøysund, Enhetsregisteret API, regnskapsdata via Proff/Regnskapstall) krever ingen samtykke — dette er allment tilgjengelig. Men i det øyeblikket du beriker med LinkedIn-data, ansattinformasjon eller kobler mot Altinn, krysser du grenser. **Implementer derfor et to-lags system:**

- **Lag 1 (uten samtykke):** Enhetsregisteret (gratis API), Brønnøysundregistrene (roller/signatur), årsregnskap via regnskapsdatabaser (Proff.no API ~15-50k/år), bransjekoder (NACE), Kartverket, evt. offentlige anskaffelser (Doffin).
- **Lag 2 (med databehandleravtale/samtykke):** Kundens egne systemer via eksport, organisasjonskart, Altinn-data (krever fullmakt), systemlandskap.

**Go/no-go:** Lag 1 fungerer alltid. Lag 2 krever et signert samarbeidsdokument — som også formaliserer prosjektstart. Gjør dette til en feature, ikke friksjon: «Signer her, så sparer vi dere 3 møter.»

## Strukturering for dag 1

Konsulenten får en **organisasjonsprofil** med:
- **Must-have:** Org-størrelse (ansatte), bransje/NACE, omsetning/resultat (3 år), juridisk struktur (datterselskaper), roller fra Brønnøysund, geografisk spredning.
- **Nice-to-have:** Teknologispor (jobbannonser som avslører systemlandskap — scrape Finn.no/karrieresider), bransje-spesifikke regulatoriske krav.
- **Automatisk generert:** Foreslått møteagenda basert på regler (>200 ansatte → spør om shared services; NACE=bygg → spør om prosjektregnskap).

## Sårbarhet og graceful degradation

For små bedrifter (<20 ansatte) gir offentlige kilder tynt grunnlag. **Fallback:** En 10-minutters digital «onboarding» der kunden velger fra forhåndspopulerte alternativer (ikke fritekst). Eksempel: «Vi ser dere er i bransje X — hvilke av disse prosessene er relevante?» Checkbox, ikke essay.

## Langsiktig samarbeidsarkitektur

**Dissens-punkt:** Ikke bygg dette som et engangsverktøy. Implementer det som en **levende kunnskapsbase** per kunde-ID. Når nye avdelinger skal rulles ut i fase 2-3, trekker du automatisk oppdaterte data og sammenligner med baseline. Dette reduserer kostnad over hele prosjektets levetid, ikke bare i forundersøkelsen.

## MVP

**Fase 1 (4 uker):** Enhetsregisteret API + Proff.no + regelmotor for møteagenda. Output: PDF-rapport per org.nr.
**Fase 2:** Integrasjon med kundens systemeksport (standardiserte maler for ERP/CRM-eksport) + Finn.no-scraping for teknologispor.

## Neste steg

1. **Bygg juridisk mal** — databehandleravtale for Lag 2 som samtidig fungerer som prosjektengasjement-dokument, slik at juridisk compliance og kommersiell oppstart skjer i én signatur.
2. **Prototyp Lag 1** mot Enhetsregisteret API med 10 reelle org.nr. fra tidligere kunder — valider om outputen faktisk hadde spart møtetid retrospektivt.
3. **Kartlegg sårbarhetene:** Test mot 5 bedrifter under 20 ansatte og 5 over 200 — dokumenter konkret hvor datagrunnlaget svikter, og design fallback-flyten.