Kontrollerar publiceringsstatus …
Version: 2026-10-13 · Planerat giltighetsdatum: 2026-10-13
UTKAST – ska granskas av jurist innan publicering.
UTKAST – ej gällande
Integritetspolicy
Detta är ett arbetsutkast för Envovera. Bolagsuppgifter, rättsliga grunder, lagringsfrister, leverantörsavtal och internationella överföringar behöver fastställas innan texten kan publiceras som gällande policy. Versionsdatumet ovan är utkastets tekniska versions-id, inte ett besked om att policyn har trätt i kraft.
Vem ansvarar för uppgifterna?
Envovera tillhandahålls av [BOLAGSNAMN], organisationsnummer [ORG.NR], [ADRESS]. Kontakt för dataskyddsfrågor: marcus.ohman09@envovera.com.
Föreslagen rollfördelning att granska: [BOLAGSNAMN] är personuppgiftsansvarig för egna ändamål som administration av tjänsten och kundkontakten. När vi behandlar personuppgifter i kundens verksamhetsdata enbart enligt kundens instruktioner är kunden personuppgiftsansvarig och vi personuppgiftsbiträde. Den senare behandlingen ska regleras i ett separat personuppgiftsbiträdesavtal. Samma uppgift kan förekomma i olika behandlingar; rollerna ska fastställas per ändamål, även för leverantörsbiblioteket.
Fråga till juristen: den tekniska felloggningen är troligen [BOLAGSNAMN]:s egen behandling för drift och säkerhet, inte en behandling på kundens uppdrag. Fastställ roll, rättslig grund och lagringsrutin separat. Detta är en preliminär rollbedömning, inte ett fastställt avtalsvillkor.
Vilka uppgifter finns i tjänsten?
| Uppgifter | Varifrån de kommer och varför de behandlas |
|---|---|
| E-postadress, användar-id, eventuell profil med namn samt autentiserings- och sessionsuppgifter | Från dig och autentiseringstjänsten, för konto, inloggning, e-postbekräftelse och återställning. Lösenord hanteras av autentiseringstjänsten och visas inte i Envoveras app. |
| Företagsnamn, organisationsnummer, land, rapportmottagare och medlemsroller | Från företaget och dess användare, för att skilja företagens data åt och ge rätt åtkomst. Uppgifter om enskild firma kan vara personuppgifter. |
| Kollegans e-postadress, vald roll, inbjudande användare, tider och inbjudans status | Från företagets ägare, för att bjuda in och administrera kollegor. Databasen sparar en hash av inbjudningskoden. |
| Produkter, förpackningar, material, vikter, källanteckningar, order- och försändningsnummer, datum, land och antal | Från kunden och valda leverantörsuppgifter, för förpackningsbokföring, kontroller och rapportunderlag. Ordernummer och fritext kan vara personuppgifter om de kan kopplas till en person. |
| Historik över import, kopiering, klassgodkännande, bekräftad packning och granskning | Från användarens handlingar; kan innehålla användar-id, tidsstämplar och ögonblicksbilder, för spårbarhet. |
| Dokumentversioner som tagits del av/godkänts och tidpunkt | Från godkännandeflödet när dokument publiceras. Appens godkännandetabell sparar inte IP-adress eller webbläsaridentifierare. |
| Begäran om företagsradering, företags-id/namn, användar-id, status och tider | Från ägare och plattformsadministratör, för att hantera och följa upp begäran. |
| Teknisk fellogg: användar-id, företags-id när företagskoppling finns, tidpunkt, sidans adress utan id:n, felkategori, felkod och appversion samt fasta tekniska uppgifter om felkälla och eventuell HTTP-status | Från appen vid fel för inloggade användare, för felsökning och stabil drift. Inga ursprungliga felmeddelanden i klartext, e-postadresser, token eller stackspår sparas. Högst 30 rader per användare och timme; samma fel inom tio sekunder räknas bara en gång. Loggvyn är för plattformsadmin. Företagets loggrader ingår också i företagets JSON-export. |
| Leverantörsdokument, dokumentuppgifter och granskningskandidater | Från plattformsadministratörens dokumentimport, för att strukturera och granska leverantörsuppgifter. Dokument kan innehålla namn och kontaktuppgifter. |
Lägg inte in slutkunders namn, adresser, känsliga personuppgifter eller annan onödig personinformation i produktnamn, orderreferenser, dokument eller fritext. Tjänstens rapportflöde behöver material- och försäljningsuppgifter, inte en kundadressbok.
Ändamål och rättslig grund — behöver fastställas
För kontoadministration, företagskontakt och säker drift behöver [BOLAGSNAMN] dokumentera vilken rättslig grund som gäller. Avtal kan vara aktuellt när den registrerade själv är avtalspart. För anställda hos en företagskund behöver normalt en annan grund, exempelvis berättigat intresse med dokumenterad intresseavvägning, bedömas. Detta utkast fastställer inte den avvägningen.
Kunden bestämmer ändamål och rättslig grund för de personuppgifter som behandlas på kundens uppdrag. Ett godkännande av användarvillkoren eller en bekräftelse på att du tagit del av policyn är inte ett generellt samtycke till all personuppgiftsbehandling.
Vem kan få tillgång?
Företagets behöriga användare kan se företagets uppgifter, medlemslista och inbjudningsuppgifter enligt sina roller. En person med en giltig inbjudningslänk kan se vilket företag och vilken e-postadress länken avser. Dela därför länken endast med den avsedda mottagaren. Företagets ägare skapar och delar kollegans länk själv; detta flöde skickar inte automatiskt ett inbjudningsmejl.
Plattformsadministration och teknisk drift omfattar administrativa funktioner. Intern behörighetstilldelning, sekretessrutiner och faktisk supportåtkomst måste dokumenteras före publicering; rollskydd i koden är inte en fullständig beskrivning av driftorganisationen.
Följande tjänster har befintliga integrationer i koden. Avtalspart, region och roll som biträde/underbiträde måste verifieras mot det faktiska driftavtalet; tabellen är inte ett färdigt underbiträdesgodkännande.
| Tjänst | Befintligt användningsområde | Uppgifter som berörs |
|---|---|---|
| Supabase / Supabase-kompatibel backend i Lovable-miljön | Autentisering, databas, lagring av leverantörsdokument och serverfunktioner | Konto/session, företagsdata, teknisk fellogg och uppladdade leverantörsdokument. Kontrollera om Supabase är direkt avtalspart eller del av Lovables leveranskedja. |
| Lovable | Appmiljö samt befintligt serversideflöde för autentiseringsmejl | Exempelvis mottagaradress och bekräftelse-/återställningslänk. Inbäddad redigerarförhandsvisning har även sessionsutbyte med redigeraren. |
| OpenAI API | AI-tolkning av leverantörs-PDF, när funktionen är konfigurerad och en administratör, kund eller inbjuden leverantör uttryckligen startar den | Hela den valda PDF:en skickas för strukturerad tolkning. Adminflödet skickar även filnamn; kundflödet använder ett generiskt filnamn i AI-anropet. Vanlig rapportframtagning skickar inte kundens försäljningsdata till detta flöde. Resultatet granskas av en människa. |
Detta utkast garanterar inte att uppgifter enbart behandlas inom EU/EES. Före publicering ska behandlingsländer, åtkomst från andra länder, leverantörsled och eventuella överföringsskydd verifieras och anges. Koden ensam visar inte dessa avtalsförhållanden. Tekniska loggar hos autentiserings- och driftleverantörer kan omfatta anslutningsuppgifter; påståendet om att godkännandetabellen inte sparar IP-adress gäller inte alla driftloggar.
Appens tekniska fellogg lagras i den befintliga databasen; ingen separat extern felloggningstjänst tillkommer. Loggen är inte anonym eftersom den innehåller användar-id. Företagets medlemmar kan få ut företagets loggrader via JSON-exporten, men har inte tillgång till adminvyn eller andra företags loggar. Beskrivningen av felloggningen bygger på granskad kod; driftsättningen behöver verifieras före publicering av policyn.
Hur länge sparas uppgifterna?
| Uppgifter | Nuvarande funktion och det som återstår att besluta |
|---|---|
| Företagets registrerade verksamhetsdata och historik | Ingen allmän automatisk gallring finns i kundflödet. Uppgifterna finns kvar tills en behörig ändring/radering genomförs. Beslutade behov och gallringsfrister ska införas i en dokumenterad rutin före publicering. |
| Inbjudningar | Länken löper ut efter sju dagar. Det innebär inte att databasraden raderas. Historiken ligger kvar tills den raderas med företaget eller enligt en separat beslutad rutin. |
| Konto, profil och dokumentgodkännanden | Företagsradering tar inte bort kontot eller profilen. Kontoradering hanteras separat. Godkännanden tas bort när Auth-kontot permanent raderas; profilen kräver separat hantering. |
| Raderingsbegäranden | Sparas även efter företagsradering, inklusive användar-id och företagsnamn. Det finns ingen automatisk gallringsfrist i koden; en proportionerlig lagringstid behöver beslutas. |
| Appens tekniska fellogg | Företagskopplade loggrader raderas när företagets radering genomförs. Användar-id töms när Auth-kontot permanent raderas; detta raderar inte själva loggraden. Rader äldre än 90 dagar gallras manuellt av plattformsadmin, inte automatiskt dag 90. Loggrader utan företagskoppling ingår inte i företagets export eller radering och omfattas i stället av den manuella gallringen. |
| Leverantörsbibliotek, källdokument, säkerhetskopior, driftleverantörernas loggar och e-post | Omfattas inte av kundens vanliga företagsradering. Frister, behörigheter och raderingsrutiner behöver verifieras separat. |
Företagsägaren kan begära radering i Inställningar. Det skapar en begäran, inte omedelbar radering. Ordinarie administrativ genomföring är möjlig tidigast efter 30 dagar, och ägaren kan ångra fram till genomförandet. Ingen automatisk radering sker dag 30. Den tekniska väntetiden är inte en generell rätt att skjuta upp en registrerads begäran enligt GDPR; sådana ärenden måste bedömas och hanteras separat inom tillämpliga tidsfrister.
Export och dina rättigheter
Företagets medlemmar, inklusive ägare, kan använda Inställningar → Företagets data för att ladda ned en JSON-export av registrerade företagsdata. Exporten är inte ett fullständigt registerutdrag över en persons uppgifter: användarkonton, profiler, dokumentgodkännanden och gemensamt leverantörs-/referensmaterial ingår inte. Separata NPA-/rapportexporter innehåller rapportunderlag, inte all företagsdata. Skydda nedladdade filer; de raderas inte automatiskt när företaget tas bort.
Du kan kontakta marcus.ohman09@envovera.com för information och tillgång, rättelse, radering, begränsning, invändning och, när förutsättningarna är uppfyllda, dataportabilitet. Om behandlingen bygger på samtycke kan det återkallas för framtiden. Vi kan behöva säkerställa din identitet. Gäller uppgifterna en kunds behandling på dess eget ansvar hjälper vi till att hänvisa ärendet till kunden. Du kan lämna klagomål till Integritetsskyddsmyndigheten (IMY), www.imy.se.
Webbläsarlagring och kontakt
Sidan Cookies och lokal lagring beskriver inloggningslagring, visningsval och tillfällig lagring av inbjudningar. Appens egen kod använder inte marknadsförings- eller analyscookies och typsnitten hämtas från den egna webbplatsen. Detta ersätter inte en kontroll av den publicerade driftmiljön.
Frågor om detta utkast: [BOLAGSNAMN], [ADRESS], marcus.ohman09@envovera.com. Ingen version publiceras innan uppgifterna har kompletterats och juridiskt granskats.
### Datablad och AI-förslag — utkast för granskning
Kunden eller den inbjudna leverantören väljer själv att starta tolkningen. AI föreslår material och styckvikt med sida och utdrag; avgiftsklass föreslås inte. Kunden godkänner innan materialposten ändras. Datablad, förslag och användningslogg (företag, användar-id när inloggad, tid, modell, promptversion och status) lagras i företagets privata data. Högst 20 försök per företag och UTC-dag tillåts, även misslyckade försök. Företagets medlemmar kan läsa dessa uppgifter och exportera dem som JSON; PDF-innehållet hämtas separat.
Vid genomförd företagsradering raderas posterna och de privata PDF-filerna köas för separat administrativ filstädning. Filerna försvinner därför inte omedelbart med databastransaktionen. Användar-id töms när kontot raderas. Gemensamma biblioteksdokument berörs inte. Rollfördelning, lagringstider, OpenAI-avtal och eventuella överföringar ska granskas av jurist före publicering. Status är fortsatt utkast.