Huoltosopimuksen tiedot digitaaliseen kotiprofiiliin

Digitaaliseen kotiprofiiliin vietävä huoltosopimustieto kannattaa jäsentää niin, että jokaisella palvelulupauksella on kohde, vastuutaho, käynnistin, tulos ja voimassaolon rajaus. Tällöin sopimus ei muutu irralliseksi dokumentiksi, vaan siitä voidaan johtaa huoltoa ohjaavia ja myöhemmin tarkistettavia tietoja.

Tämä artikkeli käsittelee tiedon mallintamista ja luovutusta kiinteistöhuollon ammattilaisen näkökulmasta. Se ei määritä tietyn digitaalisen palvelun toimintoja, tietojen säilytysaikoja tai osapuolten oikeudellisia rooleja. Ne sovitaan kohteen ja käytetyn järjestelmän mukaan.

Aloita käyttötarkoituksesta ja sopimusrajasta

Tietomallia ei pidä rakentaa käyttöliittymän kentistä taaksepäin. Ensin rajataan päätökset ja työvaiheet, joita tiedon on tuettava, ja vasta sen jälkeen valitaan tallennettavat tiedot, lähteet ja ylläpitäjät. Huoltosopimuksen sisällön ja digitaalisen tietueen välinen yhteys säilytetään lähdeviitteellä: rakenteinen tieto auttaa toteutusta, mutta ei saa huomaamatta laajentaa tai muuttaa hyväksyttyä sopimusta.

Erota asiakirja, tietue ja työmääräin

Sopimusasiakirja ilmaisee osapuolten hyväksymät ehdot. Digitaaliseen profiiliin tallennettu tietue on rakenteinen esitys yhdestä tiedosta tai säännöstä. Työmääräin puolestaan ohjaa yksittäistä suoritusta ja tallentaa toteuman. Näitä ei pidä sulauttaa toisiinsa: työmääräimen suoritusmerkintä ei muuta palvelusopimusta, eikä tietokentän muokkaus itsessään ole sopimusmuutos.

Käyttötarkoitus määrittää tallennettavan tarkkuuden. Huollon suunnittelija tarvitsee tehtävän toistuvuuden, määräajan tai laukaisimen, kohteen, vastuuroolin ja edellisen toteuman. Tilaaja voi tarvita lisäksi sopimusversion, palvelutasolupauksen, poissulun ja hyväksyntätiedon. Kenttähenkilö tarvitsee käytännön työohjeen ja turvallisuuteen liittyvät tiedot. Kaikkea ei silti tarvitse esittää samassa näkymässä.

Ennen tuontia kootaan tietoluettelo, joka vastaa neljään kysymykseen: mitä työtä tällä tiedolla tehdään, kuka tarvitsee tiedon, mistä tieto on saatu ja milloin se tarkistetaan uudelleen. Jos vastausta ei ole, kenttä voi olla tarpeeton tai sen omistajuus epäselvä.

Määrittele tietolähteiden etusija

Yksi sopimussääntö voi esiintyä tarjouksessa, pääsopimuksessa, tehtäväliitteessä ja myöhemmässä muutosasiakirjassa. Profiiliin ei siirretä vain viimeksi avattua versiota. Jokaisesta tietueesta säilytetään viite lähdeasiakirjaan, version tunnisteeseen, päiväykseen ja hyväksymiseen. Jos asiakirjat ovat ristiriidassa, ratkaisu tehdään sopimuksessa sovitun etusijajärjestyksen tai osapuolten hyväksymän tulkinnan perusteella.

Työohje voidaan liittää palveluun, mutta se pidetään sopimusehdosta erillään. Esimerkiksi kuukausittainen käyttöliittymän muistutus voi auttaa tekemään tehtävän ajallaan, mutta se ei itsessään muuta sovittua käyntitiheyttä. Muutos vaatii osapuolten sovitun hyväksymisen ja uuden version jäljen.

Tiedon omistajuuden peruskysymykset

Taulukon ylläpitovastuu tarkoittaa tiedon käytännön päivittämistä. Se ei määritä henkilötietojen käsittelyroolia. Tietosuoja-asetuksen 4 artiklan mukaan rekisterinpitäjä määrittelee käsittelyn tarkoitukset ja keinot, kun taas käsittelijä käsittelee henkilötietoja rekisterinpitäjän lukuun. Euroopan tietosuojaneuvoston rooliohje korostaa käsitteiden toiminnallista luonnetta. Rooli arvioidaan käsittelytoimittain tosiasiallisen päätösvallan ja toiminnan perusteella; sopimuksen roolinimike ei yksin ratkaise sitä.

Muunna sopimus operatiiviseksi tietomalliksi

Operatiivinen tietomalli yhdistää sovitun palvelun lähteen, tehtävän toteutuksen ja muutoksen hyväksynnän ilman, että niiden oikeudellinen tai toiminnallinen merkitys sekoittuu. Kenttien on oltava riittävän täsmällisiä työjonon muodostamiseen, mutta niitä ei pidä täydentää oletuksilla silloin, kun sopimuksesta puuttuu päätöskriteeri. Tietosanasto, versiohistoria ja epävarmuuden tila muodostavat mallin laadun perustan.

Käytä selkeitä kenttiä

Yksittäisestä tehtävätietueesta tulisi löytää ainakin yksilöivä tunniste, palvelun kohde, kuvaus, laukaisin, tavoiteltu tulos, vastuurooli, rajaukset, lähdeviite, voimassaolo ja tarkistusajankohta. Jos järjestelmä ei tue kaikkia kenttiä, kriittiset tiedot säilytetään hallitussa liitteessä ja järjestelmässä käytetään viitettä. Pitkää sopimustekstiä ei kannata kopioida vapaatekstikenttiin siten, että eri käyttäjät alkavat muokata rinnakkaisia versioita.

Laukaisin voi olla kalenteripäivä, käyttötilanteen muutos, havainto tai hälytys. Sen merkitys kirjataan täsmällisesti: ”neljännesvuosittain” ei kerro, lasketaanko jakso kalenterivuodesta vai aloituspäivästä, ja ”tarvittaessa” jättää päätöskriteerin avoimeksi. Jos sopimus ei sisällä tarkempaa ehtoa, tietomalli ei keksi sitä, vaan nostaa sen tarkistettavaksi.

Tehtävässä erotetaan vaadittu työ ja toivottu lisäpalvelu. Pakolliselta näyttävä käyttöliittymämerkintä voi laajentaa palvelun sisältöä, jos ammattilaiset alkavat käsitellä sitä sopimusvelvoitteena. Siksi tietueella on tyyppi, esimerkiksi sovittu tehtävä, sovittu vaste, poissulku, työohje tai avoin tulkinta. Käyttäjänäkymässä tyyppi esitetään ymmärrettävästi.

Säilytä aikaleimat ja versiot

Sopimuskausi ja tietueen versio ovat eri asioita. Sopimus voi pysyä voimassa, vaikka laitteen sijainti päivittyy, tai uusi sopimusversio voi muuttaa tehtävärajausta. Profiilissa säilytetään tiedon voimaantulopäivä, päättymispäivä jos tiedossa, kirjausajankohta, muuttaja ja muutoksen syy. Aiempi arvo jää tarvittaessa tarkastettavaksi sovitun säilytys- ja poistokäytännön mukaisesti.

Järjestelmän päivämääräkentässä tulee erottaa tehtävän tavoitepäivä toteutuspäivästä ja tiedon tarkistuspäivästä. Muuten raportti voi näyttää, että huolto tehtiin, vaikka vain tehtävän määräaika siirtyi. Kelloaikoja sisältävissä integraatioissa sovitaan aikavyöhyke ja aikaleimojen muoto, erityisesti jos järjestelmät toimivat eri maissa tai kesäaikaan.

Muutoksen hyväksyntäketjuun kirjataan esittäjä, tarkistaja, hyväksyjä sekä linkki hyväksyttyyn asiakirjaan tai päätökseen. Käyttöoikeus muuttaa tietueita rajataan tehtävän mukaan. Näin tietojen ylläpito ei jää kaikille yhteiseksi mutta kenellekään kuulumattomaksi työksi.

Vältä epäselviä ja päällekkäisiä kenttiä

Kaksi eri kenttää, kuten ”huoltopäivä” ja ”suoritettu”, voi tarkoittaa samaa tai eri asiaa. Tietosanastossa määritellään jokaisen kentän merkitys, sallitut arvot, yksikkö, lähde ja päivityssääntö. Jos tieto on epävarma, siihen merkitään tila, kuten vahvistettu, lähteestä tuotu, kentällä tarkistettava tai vanhentunut. Epävarmuutta ei piiloteta tyhjällä kentällä, jos se vaikuttaa työn turvallisuuteen tai sovittuun palveluun.

Yksikkö ja koodisto ovat tärkeitä myös mittauksissa. Arvo ”75” on hyödytön ilman suuretta ja yksikköä. Tässä artikkelissa ei anneta LVI-järjestelmien hyväksymisrajoja; ne tulevat suunnitelmasta, laiteohjeesta tai asiantuntijan määrittämästä menettelystä. Tietomalli tallentaa menetelmän ja yksikön, ei keksi raja-arvoa.

Huomioi huoltotiedon laatu ja henkilötiedot

Huoltotiedon laatu on sekä käytettävyyden että vastuiden kysymys. Laitteen, sopimusversion tai vastuuroolin virhe voi ohjata työn väärään kohteeseen, kun taas tarpeettoman henkilötiedon kerääminen kasvattaa tietosuojariskiä ilman vastaavaa hyötyä. Prosessissa erotetaan rakennuksen ylläpitotiedon ajantasaisuus, palveluntuottajan sovittu tiedontuotanto ja henkilötietojen käsittelyä koskevat velvoitteet.

Tee täsmällisyydestä prosessi

Rakentamislain 139 § käsittelee käyttö- ja huolto-ohjeen sisältöä, rakennuksen ylläpidon seurantatietoja sekä huolto-, korjaus- ja muutostöissä tehtyjen toimenpiteiden merkitsemistä. Pykälä säätää myös omistajan vastuusta ohjeen ajantasaisuudesta. Laatimisvelvoite koskee uutta rakennusta sekä rakentamislupaa edellyttävän korjauksen, muutostyön tai käyttötarkoituksen muutoksen toimenpidealuetta. Digitaalisen profiilin käyttöönotto ei yksin ratkaise vanhan rakennuksen ohjevelvoitetta. Palveluntuottajan käytännön tehtävä voi olla sovitun toteumatiedon tuottaminen, mutta tietueen tallentaminen ei siirrä omistajan lakisääteistä vastuuta.

Täsmällisyys varmistetaan lähde- ja kenttätarkistuksella. Laitteen mallia ei merkitä varmaksi vain siksi, että vanha piirustus niin sanoo. Kirjauksen voi merkitä ”kentällä varmistettu”, jos työntekijä tunnisti laitteen sovitulla tavalla, ja lisätä todisteen tyypin, kuten kuvan tai kilpitiedon. Kiinteistön huoltokirjaa koskeva taustaopas kuvaa ylläpitotiedon yleistä käyttöä; digitaalinen kotiprofiili tarvitsee lisäksi tiedon alkuperän, version ja varmennustilan. Kuvan sisältöä ja henkilötietoja koskevat käytännöt määritetään erikseen.

Muutosprosessissa valitaan päivittyykö tieto automaattisesti vai vaatiiko se hyväksynnän. Esimerkiksi vaihdetun suodattimen toteumamerkintä voi siirtyä suorituksesta, mutta järjestelmän suunnitellun huoltovälin muuttaminen edellyttää lähteen ja hyväksyjän tunnistamista. Automaattinen synkronointi ilman muutossääntöä voi monistaa virheen kaikkiin kohteisiin.

Minimoi henkilötiedot ja rajaa käyttö

Digitaalinen kotiprofiili voi sisältää asukkaan nimen, puhelinnumeron, pääsytiedon tai vikailmoituksen kuvauksen. EU:n yleisen tietosuoja-asetuksen 5 artikla edellyttää muun muassa käyttötarkoitukseen nähden tarpeellisten tietojen rajaamista sekä henkilötietojen täsmällisyyttä ja ajantasaisuutta. Tämä ei ole yleinen lupa tallentaa kaikkea huoltoa helpottavaa tietoa. Käsittelylle tunnistetaan myös 6 artiklan mukainen oikeusperuste; hyödyllinen käyttötarkoitus ei yksin riitä. Tässä mallissa ei valita yksittäisen palvelun oikeusperustetta. Ammattilainen määrittää organisaationsa vastuuhenkilöiden kanssa, miksi henkilötieto tarvitaan, kenellä on siihen pääsy ja milloin se poistetaan tai päivitetään.

Huoltotehtävässä voi usein riittää huoneisto tai yhteydenottokanava ilman asukkaan arkaluonteisia kuvauksia. Vikailmoituksen vapaatekstiä ohjataan kertomaan tekninen oire ja pääsyn järjestämiseen tarvittava tieto, ei tarpeetonta elämäntilannetta. Pääsykoodi tai avaintieto käsitellään organisaation turvallisen menettelyn mukaan; sitä ei kopioida avoimeen kenttään vain integraation helpottamiseksi.

Käyttäjäroolit kuvataan tehtäväkohtaisesti: kenttähenkilö näkee työtehtäväänsä tarvittavan tiedon, työnjohto työjonon ja tilaaja sovitun raportin. Käyttöoikeus tarkistetaan henkilön siirtyessä toiseen tehtävään ja sopimuksen päättyessä. Lokitieto auttaa selvittämään muutoksia, mutta sekin voi olla henkilötietoa ja vaatii hallitun säilytys- ja käyttöperusteen. Säilytyksen rajaaminen perustuu 5 artiklaan, ja 32 artikla edellyttää riskiä vastaavia teknisiä ja organisatorisia turvatoimia. Käyttöoikeusmalli on osa tätä arviointia, ei yksin osoitus vaatimusten täyttymisestä.

Tietosuojan osalta artikkeli antaa prosessikehyksen, ei oikeudellista arviota. Rekisterinpitäjän ja käsittelijän vastuut, tietosuojainformaatio, tietoturvaloukkauksen menettely sekä säilytysajat ratkaistaan asianmukaisesti ennen käyttöönottoa.

Liitä tieto järjestelmiin hallitusti

Järjestelmäintegraatio ei korjaa epäselvää lähdetietoa, vaan voi levittää sen nopeasti useaan näkymään. Siksi jokaiselle kentälle nimetään ensisijainen lähde, muunnossääntö, virhepolku ja hyväksyjä. Käyttöönotossa testataan koko ketju sopimuslähteestä tehtävän syntyyn, toteumaan, raporttiin ja muutoshistoriaan asti.

Suunnittele tunnisteet ja integraatio

Integraatio tarvitsee vakaan tunnisteen, jonka perusteella sama laite tai tehtävä tunnistetaan eri järjestelmissä. Tunnisteen pitää säilyä, vaikka laitteen nimi tai sijaintikuvaus korjataan. Jos tunniste vaihtuu, vanhan ja uuden yhteys säilytetään muutoshistoriassa. Osoitteeseen tai vapaatekstiin perustuva täsmäytys on altis kirjoitusvirheille ja samannimisille laitteille.

Kenttien vastaavuustaulukossa nimetään lähdejärjestelmän kenttä, kohdejärjestelmän kenttä, muunnossääntö, pakollisuus, virhetilanne ja vastuuhenkilö. Sovitaan myös, kumpi järjestelmä on kunkin tiedon ensisijainen lähde. Jos molemmat järjestelmät voivat kirjoittaa samaan kenttään, tarvitaan ratkaisu ristiriitatilanteeseen eikä hiljainen viimeisin kirjoitus voita automaattisesti.

Kun järjestelmää päivitetään, muutoksenhallinta kattaa testauksen, palautussuunnitelman, käyttäjätiedotteen ja virheiden seurannan. Testiympäristössä kannattaa käyttää kuvitteellista aineistoa, jos oikeita henkilötietoja ei tarvita. Oikean aineiston käyttö arvioidaan erikseen; pelkkä nimien poistaminen ei tässä mallissa ole osoitus anonymisoinnista. Käyttöönottopäätös dokumentoi rajaukset ja hyväksytyt puutteet.

Mittaa tiedon laatua hyödyllisesti

Tiedon laatua voidaan seurata esimerkiksi kattavuudella, tunnisteiden yksikäsitteisyydellä, lähdeviitteiden olemassaololla, vanhentuneiden tietojen määrällä ja epäonnistuneiden tuontien käsittelyajalla. Mittarin määritelmässä kerrotaan perusjoukko, laskentatapa ja tarkasteluajankohta. Puuttuvan tiedon prosenttiosuutta ei pidä käyttää laatutavoitteena ilman tietoa siitä, mitkä kentät ovat toiminnan kannalta pakollisia.

Laatupoikkeama viedään omistajalle. Kuvitteellisessa laskentaesimerkissä huoltokirjassa on 40 laitetta mutta vain 32:lla on tunniste. Tällöin puuttuvat kahdeksan yksilöidään tehtäviksi eikä kattavuuslukua käsitellä korjauksena. Otantatarkistus voi varmistaa tietyn aineiston osan, mutta tulos ilmoitetaan otoksen rajauksella.

Muutoshistoriaa voidaan tarkastella sen selvittämiseksi, johtuuko poikkeama lähteestä, muunnoksesta vai käyttöliittymän tallennuksesta. Järjestelmävirhe ja virheellinen lähdetieto ovat eri korjauskohteita. Palautteen tulee kulkea takaisin oikeaan ylläpitoprosessiin, jotta sama virhe ei palaa seuraavassa synkronoinnissa.

Käyttöönoton työjärjestys

Käyttöönotto etenee pienestä, tarkistettavasta tietojoukosta kohti laajempaa tuotantokäyttöä. Työjärjestys tekee näkyväksi sen, milloin sopimuslähteet, tietosanasto, vastuut, henkilötietojen rajaus ja integraation virhepolku on hyväksytty. Seuraavat vaiheet ovat toimituksellinen prosessimalli, eivät sellaisenaan laissa määrätty menettely.

1. Rajaa tiedon käyttötarkoitus. Nimeä käyttäjäryhmät ja päätökset, joita tiedolla tehdään.
2. Luettele sopimuslähteet. Tallenna versiot, hyväksynnät ja ristiriidat.
3. Rakenna tietosanasto. Määritä kenttä, tyyppi, yksikkö, lähde ja päivityssääntö.
4. Sovi omistajuus. Nimeä ylläpitäjä, hyväksyjä ja muutoksen tekijä rooleittain.
5. Tee tiedon laadun kartoitus. Tunnista puutteet, kaksoiskappaleet ja epävarmuus.
6. Määritä henkilötietojen rajat. Sopikaa käyttötarkoitus, pääsy, säilytys ja poistaminen vastuuhenkilöiden kanssa.
7. Kuvaa integraatiot. Valitse ensisijainen lähde ja virheiden käsittely.
8. Testaa rajatulla aineistolla. Tarkista tehtävän synty, toteuma, muutos ja raportti.
9. Hyväksy tuotantoon. Kirjaa avoimet riskit, varamenettely ja palautuspolku.
10. Seuraa ja tarkista. Määritä laatumittarit ja uudelleenarviointi muutostilanteissa.

Tämä järjestys on työn organisointia koskeva suositus, ei laissa säädetty vaiheistus. Kohde voi vaatia lisätarkistuksia esimerkiksi turvallisuuden, sopimuksen tai tietoturvan vuoksi.

Kuvitteellinen tiedonsiirtotapaus

Kuvitteellisessa neljän asuinkerrostalon huoltopalvelussa on 140 laitetietuetta ja kahdeksan toistuvaa tehtäväryhmää. Tuontia valmisteltaessa 12 laitetta esiintyy kahdella tunnisteella, kolmelta tehtäväryhmältä puuttuu sopimusliiteviite ja päivystysyhteystiedoissa on entisen vastuuhenkilön numero. Määrät ovat harjoitusta varten keksittyjä.

Tiimi keskeyttää päällekkäisten laitetietojen automaattisen yhdistämisen. Kohdevastaava tarkistaa tunnisteet, laitekohtainen kaksoiskappale yhdistetään vasta lähdeasiakirjan ja kohdehavainnon perusteella. Kolmen tehtäväryhmän sisältöä ei päätellä aiemmista kohteista, vaan tilaajalta pyydetään hyväksytyt sopimusliitteet. Päivystysnumero tarkistetaan toimivaltaiselta yhteyshenkilöltä ja vanhan numeron näkyvyys rajataan asianmukaisesti.

Ennen tuotantotuontia suoritetaan rajattu testi. Yksi määräaikatehtävä, yksi vikailmoitus ja yksi laitetiedon muutos kulkevat järjestelmän läpi. Tiimi tarkistaa, että tehtävän vastuurooli, ajankohta, lähde, toteuma ja hyväksyntä näkyvät oikeille käyttäjille. Testi ei todista kaikkien 140 tietueen virheettömyyttä, joten jäljelle jäävä aineisto käsitellään erikseen määritellyllä otannalla ja poikkeamalistalla.

Käyttöönottopäätökseen kirjataan hyväksytty tietojoukko, hylätyt tietueet, avoimet tehtävät, yhteyshenkilö ja paluumenettely. Tietomallin omistaja sopii tarkistuksen sen jälkeen, kun ensimmäiset tuotantototeumat ovat kertyneet. Näin suunnitteluoletuksia verrataan todelliseen käyttöön.

Hyväksymiskortti ennen käyttöönottoa

Hyväksymiskortti kokoaa käyttöönoton portin yhdelle sivulle. Jokaisesta kohdasta merkitään tila sekä näyttö tai jatkotoimi; pelkkä kyllä-vastaus ei riitä, jos tietolähdettä tai hyväksyjää ei pystytä osoittamaan. Kortti mukautetaan järjestelmän, kohteen, sopimuksen ja riskien mukaan.

Hyväksymiskortin tulos voi olla hyväksytty, ehdollinen tai palautettu. Ehdollisessa hyväksynnässä on kerrottava, mikä osa voidaan ottaa käyttöön ja mitä tietoja ei käytetä päätöksenteossa ennen varmennusta. Vastuu hyväksynnästä kuuluu sovitulle toimivaltaiselle taholle.

Yhteenveto

Digitaalisen kotiprofiilin hyöty syntyy siitä, että huoltotieto pysyy käyttökelpoisena sopimuskauden, tehtävän ja muutoksen yli. Jos ylläpitoa, hyväksyntää ja tiedon lähdettä ei ole määritelty, profiili voi vain nopeuttaa virheen leviämistä. Aloita rajatusta tietojoukosta, testaa todellinen työprosessi ja laajenna vasta, kun vastuut ja poikkeamien käsittely toimivat.

Sopimusasiakirja, rakenteinen tietue ja työmääräin säilytetään erillisinä mutta jäljitettävästi yhdistettyinä. Rakennuksen ylläpitotiedon, henkilötiedon ja järjestelmälokin käsittelylle määritetään omat käyttötarkoitukset, omistajat ja säilytysmenettelyt. Myös määräaikaishuoltojen tiedot kannattaa tuoda profiiliin vasta, kun toistuvuus, ankkuripäivä, kohde, vastuu ja toteuman todiste ovat yksiselitteisiä.

<!-- COMPONENT:PilotCustomerCTA -->

Usein kysytyt kysymykset

Vastaukset tiivistävät mallinnuksen keskeiset rajat. Tietosuojaroolit, oikeusperusteet, sopimuksen oikeusvaikutukset ja tekniset turvatoimet arvioidaan aina todellisessa palvelu- ja järjestelmäkokoonpanossa.

Mitä sopimustietoa kannattaa viedä digitaaliseen kotiprofiiliin?

Vie vain sellaista rakenteista tietoa, jolla on määritelty käyttötarkoitus, lähde ja ylläpidon omistaja. Tyypillisiä ovat tehtävän kohde, laukaisin, tulos, vastuurooli, rajaus ja viite voimassa olevaan sopimusversioon.

Voiko profiili korvata allekirjoitetun sopimuksen?

Tietue voi auttaa sopimuksen operatiivisessa käytössä, mutta sen asema määräytyy sopimuksen ja osapuolten hyväksymän menettelyn mukaan. Kentän päivitystä ei pidä tulkita sopimusmuutokseksi ilman sovittua hyväksyntäketjua.

Kuka vastaa huoltotiedon oikeellisuudesta?

Vastuut riippuvat tiedon lähteestä, sopimuksesta ja tehtävänjaosta. Rakentamislain mukaan rakennuksen omistaja vastaa käyttö- ja huolto-ohjeen ajantasaisuudesta; palveluntuottaja voi tuottaa sovittua toteumatietoa ja ilmoittaa havaitsemastaan virheestä.

Saako asukkaan yhteystiedot tallentaa huoltoprofiiliin?

Henkilötiedolle määritetään käyttötarkoitus, käsittelyn oikeusperuste, tarpeellisuus, käyttöoikeus ja säilytyskäytäntö. Tietosuoja-asetus edellyttää tietojen rajaamista tarpeelliseen ja täsmällisyyden ylläpitämistä; yksittäisen palvelun roolit ja käytännöt arvioidaan erikseen.

Miten epävarma laitetieto käsitellään?

Merkitse tietue tarkistettavaksi ja nimeä omistaja sekä määräaika. Älä käytä epävarmaa arvoa huoltopäätöksen perusteena, jos se voi ohjata työn väärään laitteeseen tai muuttaa sovittua tehtävää.

Lähteet

Lähteet tukevat säädös- ja rooliväitteitä. Todelliset järjestelmäkohtaiset ominaisuudet, tietovirrat, sopimusrakenne ja tietosuojamenettelyt tarvitsevat nimetyn ihmisasiantuntijan hyväksynnän ennen julkaisua.

• Finlex: rakentamislaki 751/2023, 139 § – rakennuksen käyttö- ja huolto-ohje
• EUR-Lex: yleinen tietosuoja-asetus (EU) 2016/679, johdanto-osan 26 kappale sekä 4–6 ja 32 artikla
• Euroopan tietosuojaneuvosto: rekisterinpitäjän ja henkilötietojen käsittelijän käsitteet, ohje 07/2020