Säkerhet och data
Var era uppringares data ligger, och vem som kan komma åt dem
Ett telefonsamtal hör till det känsligaste en verksamhet lagrar: ett namn, ett personnummer, en medicinsk situation, en rättstvist — uttalade högt och sparade. Den här sidan beskriver vad systemet faktiskt gör med det, inklusive det vi inte har.
Kort svar
Vad händer med personuppgifter som sägs under ett samtal med en AI-agent?
Varje transkript passerar ett lager som upptäcker och maskerar identifierande uppgifter och som är anpassat för hebreiska, och varje avdelning avgör själv vilka entitetstyper som maskeras hos den. Åtkomst till inspelningar och transkript begränsas per roll, och känsliga åtgärder skrivs till en granskningslogg. En medborgares begäran om radering har ett eget flöde som nollställer uppringarens identifierare, täcker över avsnitten med personuppgifter i transkriptet, kopplar bort inspelningen och stämplar ett referensnummer som ni kan uppge för personen. Reglerade verksamheter kan köra hela systemet innanför sin egen perimeter, modellvikterna inkluderade, så att inga samtalsdata lämnar nätverket. Vi innehar ingen revisionscertifiering enligt någon säkerhetsstandard, och vi påstår inget annat.
Det vi inte har — före det vi har
Vi har inte SOC 2, vi har inte ISO 27001 och vi är varken HIPAA- eller GDPR-certifierade. Något «GDPR-certifikat» finns över huvud taget inte, och HIPAA är amerikansk reglering som inte gäller för de flesta som läser här — men de förekommer på så många säkerhetssidor att det är värt att säga rakt ut att de inte förekommer på vår. I stället för att antyda en ackreditering vi inte har beskriver allt nedan kontroller som verkligen finns i produkten, och vi visar gärna var och en av dem live mot ett system i drift. Om standarden ni måste uppfylla kräver en certifierad leverantör säger vi det redan vid första samtalet, inte i upphandlingsskedet.
Upptäckt och maskering av personuppgifter
Ett transkript av ett samtal på hebreiska är fullt av precis det som inte får ligga i klartext: ett fullständigt namn, ett personnummer dikterat siffra för siffra, en adress, ett telefonnummer, namnet på en läkare eller en institution. Systemet kör ett entitetsigenkänningslager tränat på hebreiska över varje tur i samtalet — inte en allmän motor som behandlar hebreiska som en eftertanke. Det som hittas sparas som positioner i texten, så transkriptet kan visas maskerat för den som inte ska se originalet, utan att möjligheten att analysera samtalet går förlorad.
- Varje avdelning bestämmer själv vilka entitetstyper som maskeras hos den — namn, personnummer, telefon, adress och mer
- En entitetstyp som systemet inte känner igen maskeras som standard i stället för att av misstag exponeras
- Efter en inställningsändring kan igenkänningen köras om över tidigare samtal, så att det förflutna motsvarar nuet
- Maskeringen gäller både transkript och exporter — en CSV-fil som lämnar verksamheten kan lämna den maskerad
Begäran om radering — hela flödet
En medborgare som ber om att få sina uppgifter raderade ska inte behöva nöja sig med ett muntligt löfte. En raderingsbegäran är i systemet en dokumenterad åtgärd som kan köras mot ett enskilt samtal, mot alla samtal från ett visst telefonnummer, eller mot ett datumintervall och ett ärende-id — och detta är vad den faktiskt gör:
- Uppringarens identifierare — telefonnummer, ärende-id, namn — nollställs i samtalsposten
- Varje avsnitt som identifierats som personuppgift i transkriptet ersätts med ett block och blir inte kvar i texten
- Själva träffpositionerna raderas, så att det dolda inte kan rekonstrueras ur dem
- Referensen till inspelningen töms, så uppspelningen misslyckas säkert och spelar ingenting
- Samtalet markeras som behandlat, med stämpel för vem som utförde åtgärden, när, och referensnumret
I slutet av processen stämplas ett referensnummer i fast format på posten. Det är numret som lämnas till medborgaren, och det är också det som låter er i efterhand visa att begäran hanterades, när och av vem. Parallellt skrivs en rad i granskningsloggen för varje berört samtal — inte en rad per begäran, utan en rad per post som rörts.
Vem ser vad
Behörigheter ges per roll, inte utifrån förtroende. Inspelningar är det tydligaste fallet: i ljud finns ingen maskering — en röst är en röst — så åtkomsten är begränsad till de roller som behöver den, och en avdelning som vill öppna avlyssning även för användare med enbart visningsrätt måste slå på det medvetet. Känsliga åtgärder skrivs till en granskningslogg som går att granska.
- Separata roller för administratör, kvalitetsgranskare och betraktare — och de ser inte samma sak
- Uppspelning av inspelningar är öppen för administratörer och granskare; att öppna den för betraktare är en separat, medveten inställning per avdelning
- Känsliga åtgärder — radering, export, ändrade inställningar — loggas med utförare och tidsstämpel
- Exporter passerar samma behörighetskontroller och samma loggning som visning inne i systemet
Tre driftsformer
Samma system, tre olika svar på frågan «hur mycket av omvärlden rör vid dessa data». Valet är ert, inte vårt.
Delat moln
Den snabba vägen. Vi driver systemet, och varje organisations data är isolerade från alla andras. Passar verksamheter som inte omfattas av reglering som föreskriver kontroll över infrastrukturen. Vissa modelltjänster är i den här formen externa tjänster — det säger vi rakt ut, eftersom det är precis det en reglerad verksamhet inte kan acceptera.
Hybriddrift
Dataplanet — databasen, inspelningarna, maskeringslagret och skyddsräckena — ligger på infrastruktur som ni kontrollerar, medan själva modellerna körs på separat dedikerad hårdvara som avtalas med er. En medveten kompromiss: billigare än full drift hos er, men inte lämplig för varje informationsklassning, och vi säger till när den inte är det.
Full drift i egen regi
Hela systemet körs innanför er perimeter, modellvikterna inkluderade — taligenkänning, språkmodell och talsyntes. I praktiken: inget ljudavsnitt och inget transkript lämnar ert nätverk till någon extern leverantör, inte heller till oss. Det är formen som byggts för myndigheter och reglerade organisationer, och den stöds även i en miljö som är avskild från externt nät.
Anpassningsarbete mot הנחיה 5.43 (israelisk direktiv för informationssäkerhet)
För israeliska myndigheter är informationssäkerhetsdirektivet הנחיה 5.43 den referensram som faktiskt gäller — inte SOC 2. Vi bedriver ett anpassningsarbete mot dess krav: rollbaserad åtkomstkontroll, loggning av åtgärder i ett granskningsspår, minimering av personuppgifter genom maskeringslagret, och möjligheten att köra samtliga komponenter innanför organisationens eget nätverk. Låt oss vara exakta: anpassningsarbete är varken ett godkännande eller en ackreditering, och vi visar upp inget godkännande från någon myndighet. Skillnaden mellan de två går vi gärna igenom punkt för punkt tillsammans med er informationssäkerhetsansvarige.
Det ni bör fråga oss
Om ni utvärderar leverantörer på det här området är detta frågorna som skiljer en säkerhetssida från en produkt. Ställ dem till oss också.
- Fungerar maskeringen av personuppgifter verkligen på hebreiska, eller är det en engelsk motor riktad mot hebreisk text?
- Vad händer exakt med en post efter en raderingsbegäran — och vad finns kvar för att visa att raderingen skedde?
- Är inspelningen åtkomlig för samma personer som transkriptet, eller är de två åtskilda?
- Om vi kräver att data aldrig lämnar vårt nätverk — körs modellerna hos oss, eller bara databasen?
- Vilka formella certifieringar har ni faktiskt, och vilken av dem är relevant för standarden jag svarar mot?
Ring AI-agenten nu
Ett riktigt samtal, på hebreiska. Exakt vad de som ringer er skulle höra.
Låt AI-agenten ringa upp dig
Lämna ett nummer — agenten ringer upp inom en minut.
Uppdaterad: