Tallennetut haut ovat rekrytoinnissa kahden eri asian nimi: työnhakijalle ne ovat hakuvahteja, jotka ilmoittavat uusista kriteereitä vastaavista työpaikoista, ja rekrytoijalle ne ovat uudelleen käytettäviä hakulausekkeita, joilla ehdokastietokanta, talent pool ja avoin verkko käydään läpi aina samoilla, testatuilla ehdoilla. Tämä artikkeli käsittelee erityisesti jälkimmäistä näkökulmaa: miten IT-rekrytointitoimisto, suorahakukonsultti tai HR-osasto rakentaa tallennetuista hauista toistettavan työkalun, miten niistä saadaan lisää esitettäviä kandidaatteja ilman lisähenkilöstöä ja mitä tietosuoja-asetus edellyttää, kun haun tuloksena syntyy henkilörekisteri.

Tärkeimmät havainnot

• Tallennettu haku on prosessin osa, ei pelkkä pikanäppäin: sen arvo syntyy siitä, että sama hakulogiikka ajetaan uudelleen jokaisen samankaltaisen toimeksiannon kohdalla ja tulokset arvioidaan yhtenäisillä kriteereillä.

• Paras lähde on usein oma tietokanta: hyvin indeksoitu talent pool palauttaa näkyviin ehdokkaat, jotka muuten unohtuisivat, ja vähentää riippuvuutta ulkoisten alustojen lisensseistä.

• Jokainen tallennettu tulos on henkilötietoa: käsittelyperuste, tiedonantovelvollisuus ja säilytysaika on ratkaistava ennen kuin haku ajetaan, ei vasta sen jälkeen.

• Talent pool ei oikeuta loputtomaan säilytykseen: rekrytoinnin päättyminen ei automaattisesti siirrä hakijaa pooliin, vaan siirto edellyttää erillistä informointia ja usein suostumusta.

• Poistaminen on teknisesti vaativampaa kuin tallentaminen: tiedot on poistettava myös hakuvahdeista, raporteista ja integraatioista.

Sisällysluettelo

• Sisällys

• 1. Mitä tallennettu haku tarkoittaa rekrytoinnissa

• 2. Tallennettujen hakujen tyypit rekrytoijan työssä

• 3. Toimivan tallennetun haun rakentaminen vaihe vaiheelta

• 4. Tallennetut haut ja talent pool: oman tietokannan hyödyntäminen

• 5. Tietosuoja: mitä GDPR ja Suomen lainsäädäntö edellyttävät

• 6. Yleisimmät virheet tallennettujen hakujen käytössä

• 7. Recruitifyn näkökulma

• 8. Usein kysytyt kysymykset

• Lähteet

Sisällys

1. Mitä tallennettu haku tarkoittaa rekrytoinnissa

2. Tallennettujen hakujen tyypit rekrytoijan työssä

3. Toimivan tallennetun haun rakentaminen vaihe vaiheelta

4. Tallennetut haut ja talent pool: oman tietokannan hyödyntäminen

5. Tietosuoja: mitä GDPR ja Suomen lainsäädäntö edellyttävät

6. Yleisimmät virheet tallennettujen hakujen käytössä

7. Recruitifyn näkökulma

8. Usein kysytyt kysymykset

1. Mitä tallennettu haku tarkoittaa rekrytoinnissa

Työnhakijan näkökulmasta tallennettu haku on tuttu toiminto julkisilta ja yksityisiltä työpaikkasivustoilta. Esimerkiksi Helsingin kaupungin avoimien työpaikkojen palvelussa hakija voi tallentaa haun ja käyttää hakusanana vaikkapa tietyn yksikön nimeä, jolloin palvelu seuraa juuri niitä tehtäviä, jotka häntä kiinnostavat. Periaate on yksinkertainen: hakija määrittää kriteerit kerran, ja järjestelmä lähettää sähköposti-ilmoituksen, kun uusi ilmoitus vastaa niitä.

Rekrytoijan näkökulmasta sama periaate käännetään toisin päin. Rekrytoija ei seuraa avoimia työpaikkoja vaan osaajia: hän tallentaa hakulausekkeen, joka kuvaa tietyn profiilin, esimerkiksi Java-taustaisen backend-kehittäjän, jolla on kokemusta Spring Bootista ja pilvipalveluista, ja ajaa haun uudelleen aina, kun asiakkaalta tulee samankaltainen toimeksianto tai tietokantaan tallentuu uusia profiileja. Kehittyneissä ATS- ja CRM-järjestelmissä tallennettu haku voi toimia myös aktiivisena vahtina, joka nostaa uudet vastaavuudet rekrytoijan näkyviin ilman manuaalista hakua.

Ero on merkittävä myös juridisesti. Kun hakija tallentaa hakuvahdin, hän luovuttaa itse sähköpostiosoitteensa ja hakuehtonsa tiettyä tarkoitusta varten. Kun rekrytoija tallentaa haun tulokset omaan tietokantaansa, syntyy henkilörekisteri, jonka käsittelyyn sovelletaan tietosuoja-asetusta, tietosuojalakia ja työelämän tietosuojalakia. Tästä syystä tallennettujen hakujen hallinta on yhtä lailla prosessi- kuin tietosuojakysymys.

2. Tallennettujen hakujen tyypit rekrytoijan työssä

Rekrytointitoimiston arjessa tallennettuja hakuja käytetään useaan tarkoitukseen, ja kullakin tyypillä on oma hyötynsä ja oma riskinsä. Seuraava taulukko kokoaa yleisimmät käyttötavat.

Taulukosta näkyy olennainen periaate: mitä laajemmalle haku ulottuu, sitä enemmän sen tuloksiin liittyy tietosuojavelvoitteita. Sisäinen haku kohdistuu tietoihin, joiden käsittelyperuste on jo olemassa, kun taas avoimesta verkosta tallennetut tiedot synnyttävät uusia velvoitteita heti tallennushetkellä.

3. Toimivan tallennetun haun rakentaminen vaihe vaiheelta

Tallennettu haku on vain niin hyvä kuin sen taustalla oleva profiilimäärittely. Seuraava työjärjestys toimii sekä IT-rekrytoinnissa että muissa asiantuntijatehtävissä.

1. Määritä profiili ennen hakua. Kirjaa asiakkaan kanssa pakolliset ja toivotut osaamiset erikseen. Pakolliset muuttuvat AND-ehdoiksi, toivotut OR-ryhmiksi tai pisteytyksen painotuksiksi.

2. Ota synonyymit huomioon. Sama osaaminen esiintyy CV:issä eri muodoissa: “JavaScript”, “JS”, “Node.js” tai “React-kehittäjä”. Suomalaisissa profiileissa nimikkeet vaihtelevat lisäksi kielen mukaan, esimerkiksi “ohjelmistokehittäjä”, “software developer” ja “full stack -kehittäjä”.

3. Rakenna lauseke ja testaa se. Esimerkkinä backend-profiilin lauseke voisi olla muotoa (“Java” OR “Kotlin”) AND (“Spring Boot” OR “Spring”) AND (“AWS” OR “Azure”) AND (Helsinki OR Espoo OR Tampere) NOT (harjoittelija OR trainee). Aja haku, tarkista kymmenen ensimmäistä tulosta ja säädä ehtoja, ennen kuin tallennat sen.

4. Nimeä haku kuvaavasti. Selkeä nimeäminen, kuten “Backend Java, pilvi, pääkaupunkiseutu, senior”, tekee hausta koko tiimin yhteisen työkalun eikä yhden rekrytoijan muistiinpanon.

5. Liitä haku toimeksiantoon tai asiakkaaseen. Kun haku on kytketty myyntiputken asiakkaaseen, sen tuloksia voidaan käyttää myös silloin, kun sama asiakas avaa seuraavan samankaltaisen tehtävän.

6. Aseta tarkistusväli. Päätä, ajetaanko haku automaattisesti päivittäin, viikoittain vai vain uuden toimeksiannon alkaessa, ja kuka vastaa tulosten läpikäynnistä.

7. Arvioi tulokset yhtenäisesti. Pisteytys tai prosentuaalinen sopivuusarvio auttaa vertaamaan ehdokkaita samoilla kriteereillä, mutta lopullinen arvio kuuluu aina rekrytoijalle.

Boolean-logiikan perusteet ja hakulausekkeiden rakentamisen käytännöt on koottu tarkemmin Boolean-hakukoneen esittelyyn, jossa hakulausekkeen luomista voi tarkastella osana koko sourcing-prosessia.

4. Tallennetut haut ja talent pool: oman tietokannan hyödyntäminen

Monen rekrytointitoimiston suurin käyttämätön resurssi on sen oma ehdokastietokanta. Aiemmissa prosesseissa haastatellut, toiseksi jääneet tai myöhemmin kiinnostuneiksi ilmoittautuneet ehdokkaat ovat jo tunnettuja, ja heidän osaamisensa on usein arvioitu huolellisemmin kuin yhdenkään ulkoisen alustan profiilin. Ongelma on, että ilman toimivaa indeksointia ja tallennettuja hakuja nämä ehdokkaat jäävät taulukoihin, sähköposteihin ja yksittäisten konsulttien muistiin.

Tallennetut haut muuttavat tietokannan passiivisesta arkistosta aktiiviseksi lähteeksi. Kun uusi toimeksianto avataan, rekrytoija ajaa ensin vastaavan tallennetun haun omaan talent pooliin ja vasta sen jälkeen ulkoisiin lähteisiin. Tämä järjestys lyhentää aikaa ensimmäiseen shortlistiin, alentaa hankintakustannuksia ja parantaa ehdokaskokemusta, koska jo kerran palvelussa asioinut ehdokas tunnistaa toimiston ja sen tavan toimia.

Käytännön vaikutuksista kertoo esimerkiksi asiakastarina, jossa automaatio ja talent pool lisäsivät esitettäviä kandidaatteja 40 %. Tulos ei synny pelkästä työkalusta vaan siitä, että hakujen, poolien ja muistutusten muodostama kokonaisuus on otettu osaksi päivittäistä työtä. Kokonaisuuden hallinta edellyttää myös, että ehdokasprofiilit pysyvät ajantasaisina ja duplikaatit yhdistetään, mihin kandidaattien hallinta yhdessä järjestelmässä tarjoaa rakenteen.

Tallennettujen hakujen painotus vaihtelee organisaation tyypin mukaan. Rekrytointitoimistossa ja henkilöstövuokrausyrityksessä haut palvelevat useita asiakkaita samanaikaisesti, joten niiden on oltava kytkettyinä asiakkuuksiin ja toimeksiantoihin. Yrityksen HR-osastolla painopiste on usein sisäisessä liikkuvuudessa ja aiempien hakijoiden uudelleenkontaktoinnissa, jolloin tallennettu haku kohdistuu ensisijaisesti omaan hakijarekisteriin. Kun ehdokas esitellään loppuasiakkaalle, anonymisoitu Blind CV -profiili rajaa luovutettavat tiedot siihen, mikä arvioinnin kannalta on tarpeellista.

5. Tietosuoja: mitä GDPR ja Suomen lainsäädäntö edellyttävät

Tallennetut haut ovat tehokkaita juuri siksi, että ne keräävät ja säilyttävät tietoa. Samasta syystä ne ovat rekrytoinnin tietosuojariskien keskiössä. Tietosuojavaltuutetun toimiston mukaan työnantaja saa käsitellä vain välittömästi tarpeellisia henkilötietoja, ja sama tarpeellisuusvaatimus koskee työnhakijoiden tietoja. Seuraavat kolme kysymystä on syytä ratkaista jokaisen tallennetun haun kohdalla.

Käsittelyperuste: suostumus vai oikeutettu etu

Talent poolin käsittelyperusteena käytetään yleisimmin suostumusta (GDPR 6 artiklan 1 kohdan a alakohta) tai oikeutettua etua (f alakohta). Saksalaisen tietosuoja-asiantuntijan talent poolia käsittelevässä artikkelissa todetaan, että pooliin ottaminen perustuu useimmiten suostumukseen. Suostumuksen heikkous rekrytoijan kannalta on, että hakija voi peruuttaa sen milloin tahansa, jolloin tiedot on poistettava. Oikeutettu etu voi olla kestävämpi peruste, mutta se edellyttää dokumentoitua intressivertailua siitä, miksi säilyttäminen on tarpeellista eikä loukkaa hakijan oikeuksia.

Käytännössä tämä tarkoittaa, että rekrytointiprosessin päättyminen ei sellaisenaan oikeuta siirtämään hakijaa talent pooliin. Siirto on eri käyttötarkoitus, josta hakijaa on informoitava erikseen, ja järjestelmän on pystyttävä osoittamaan, milloin ja miten suostumus on saatu. Suostumusten dokumentoinnin käytännöt on käsitelty tarkemmin oppaassa GDPR-suostumusten hallinnasta ATS:ssä.

Tiedonantovelvollisuus X-Ray- ja verkkohauissa

Kun tallennettu haku kohdistuu avoimeen verkkoon ja rekrytoija tallentaa löytämänsä profiilin omaan tietokantaansa, tiedot on kerätty muualta kuin rekisteröidyltä itseltään. Tällöin sovelletaan GDPR:n 14 artiklaa, jonka mukaan rekisteröidylle on annettava tiedot käsittelystä kohtuullisessa ajassa ja viimeistään kuukauden kuluessa. Saksalainen Hessenin tietosuojaviranomainen on arvioinut tapausta, jossa henkilöstöpalveluyritys oli koonnut ehdokastietokannan Google-haun avulla, ja rekisteröity sai tietää asiasta vasta yrityksen lähettämästä sähköpostista. Tapaus havainnollistaa, miksi aktiiviseen suorahakuun erikoistuneen toimiston on rakennettava tiedonanto osaksi hakuprosessia.

Suomessa kysymykseen vaikuttaa lisäksi työelämän tietosuojalaki, jonka lähtökohta on, että tiedot kerätään ensisijaisesti työnhakijalta itseltään. Siksi X-Ray-haun tulokset kannattaa käsitellä ensin kontaktointilistana, ja varsinainen profiili tallennetaan vasta, kun ehdokas on informoitu ja kiinnostunut. Epäselvissä tilanteissa, esimerkiksi kun haku kohdistuu laajaan joukkoon julkisia profiileja, oikea taho on organisaation tietosuojavastaava tai tietosuojaan erikoistunut juristi.

Säilytysajat ja tietojen poistaminen

Säilytysajalle ei ole yhtä lakisääteistä lukua, vaan rekisterinpitäjän on määriteltävä se ja perusteltava. Monissa organisaatioissa käytetään 1-2 vuoden aikaa, mutta organisaatiot ratkaisevat asian eri tavoin: esimerkiksi S-ryhmä kertoo säilyttävänsä työnhakutietoja 2,5 vuotta rekrytoinnin sulkemisesta, minkä jälkeen tiedot poistetaan. Esimerkki osoittaa, että säilytysajan tulee perustua organisaation omaan dokumentoituun arvioon käyttötarkoituksesta eikä toisen organisaation lukuun.

Poistaminen on tallennettujen hakujen kohdalla erityisen vaativaa. Pseudonymisointi ei ole poistamista, ja kun ehdokas poistetaan, tietojen on kadottava myös hakuvahdeista, tilastoraporteista ja integraatioista. Hakijan hakuvahti voi jättää sähköpostiosoitteen järjestelmään, vaikka itse hakemus on poistettu. Aiheesta on kirjoitettu laajemmin artikkelissa rekrytointidatan säilytysajoista.

6. Yleisimmät virheet tallennettujen hakujen käytössä

Tallennetut haut epäonnistuvat harvoin teknisesti. Useimmiten ongelma on prosessissa, ja samat virheet toistuvat toimistosta toiseen:

• Haku tallennetaan, mutta sitä ei koskaan ajeta uudelleen. Ilman omistajaa ja tarkistusväliä tallennetuista hauista muodostuu lista, jota kukaan ei avaa.

• Lausekkeet vanhenevat. Teknologiat ja nimikkeet muuttuvat nopeasti, joten hakulausekkeet kannattaa käydä läpi esimerkiksi neljännesvuosittain.

• Jokaisella konsultilla on omat hakunsa. Kun haut ovat henkilökohtaisia, toimisto menettää osaamisen, kun konsultti vaihtaa työpaikkaa.

• Tulokset viedään taulukkoon. Excel-tiedostoon viety hakutulos jää säilytysaikojen, poistopyyntöjen ja lokien ulkopuolelle, mikä on sekä tehokkuus- että tietosuojaongelma.

• Sama ehdokas kontaktoidaan kahdesti. Jos myyntiputki ja rekrytointiputki ovat eri järjestelmissä, kaksi konsulttia voi tarjota samaa ehdokasta eri asiakkaille tai samalle asiakkaalle. Kysymystä käsitellään artikkelissa ATS:n ja CRM:n eroista.

• Talent poolia pidetään pysyvänä arkistona. Ilman aktiivista yhteydenpitoa ja suostumusten päivitystä pooli muuttuu riskiksi eikä resurssiksi.

7. Recruitifyn näkökulma

Työskentelemme päivittäin IT-rekrytointitoimistojen, suorahakukonsulttien ja henkilöstövuokrausyritysten kanssa, ja näemme saman ilmiön toistuvasti: arvokkain ehdokastieto on jo toimiston omassa tietokannassa, mutta sitä ei löydetä, koska haut, ehdokasprofiilit ja asiakastiedot ovat hajallaan eri työkaluissa. Siksi pidämme tallennettuja hakuja ennen kaikkea tietokannan kaupallistamisen välineenä, emme pelkkänä hakuominaisuutena.

Näkemyksemme mukaan tallennettu haku toimii parhaiten, kun se ei ole erillinen toiminto vaan osa yhtenäistä ketjua: Boolean- ja X-Ray-haku tuottaa ehdokkaat, AI CV Parser rakentaa niistä rakenteellisen profiilin ja tunnistaa duplikaatit, Contextual Matching AI arvioi sopivuuden suhteessa projektin vaatimuksiin prosentuaalisena arviona ja automaattiset talent poolit, muistutukset ja toimintasuositukset pitävät ehdokkaat ajan tasalla. Kun myynnin CRM ja rekrytoinnin ATS ovat samassa järjestelmässä, sama haku palvelee sekä uutta toimeksiantoa että asiakkuuden seuraavaa tarvetta.

Korostamme kuitenkin, että tekoälypohjainen pisteytys ei ole musta laatikko eikä korvaa rekrytoijan harkintaa. Se nopeuttaa esikarsintaa ja tekee arvioinnista yhtenäisempää, mutta vastuu ehdokkaan valinnasta ja tietojen käsittelyn lainmukaisuudesta säilyy aina toimistolla. Tästä syystä pidämme toimintahistorian kaltaista audit-kelpoista dokumentaatiota yhtä tärkeänä kuin itse hakutoimintoja.

- Recruitify Team

Recruitify tallennettujen hakujen ja talent poolien hallintaan

Recruitify yhdistää ATS:n, myynnin CRM:n ja body leasing -toiminnan hallinnan yhdeksi alustaksi, jossa Boolean- ja X-Ray-haut, talent poolit, sopivuusarviot ja Blind CV -profiilit ovat samassa näkymässä. HR Team -paketti on saatavilla alkaen 61 € kuukaudessa käyttäjää kohden ja Agency-paketti alkaen 67 € kuukaudessa käyttäjää kohden, ja suuremmille organisaatioille on tarjolla Enterprise-paketti. Pakettien sisällön voi vertailla ATS:n ja CRM:n hinnastossa.

8. Usein kysytyt kysymykset

Mikä ero on hakuvahdilla ja rekrytoijan tallennetulla haulla?

Hakuvahti on työnhakijan työkalu, joka lähettää ilmoituksen uusista hakukriteereitä vastaavista työpaikoista. Rekrytoijan tallennettu haku kohdistuu ehdokkaisiin: se ajaa saman hakulausekkeen uudelleen omaan tietokantaan, talent pooliin tai avoimeen verkkoon. Molemmissa käsitellään henkilötietoja, mutta rekrytoijan haussa tietosuojavastuu on selvästi laajempi.

Saako X-Ray-haulla löydetyn profiilin tallentaa omaan tietokantaan?

Tallentaminen on mahdollista, mutta se edellyttää käsittelyperustetta ja GDPR:n 14 artiklan mukaista tiedonantoa viimeistään kuukauden kuluessa. Suomessa on lisäksi huomioitava työelämän tietosuojalain periaate, jonka mukaan tiedot kerätään ensisijaisesti hakijalta itseltään. Jos toimintatapa on epäselvä, asia kannattaa käydä läpi tietosuojavastaavan tai tietosuojajuristin kanssa ennen laajamittaista hakua.

Kuinka kauan talent poolin ehdokastietoja voi säilyttää?

Laissa ei ole yhtä kiinteää aikaa, vaan rekisterinpitäjä määrittelee ja perustelee säilytysajan itse. Yleinen käytäntö on 1-2 vuotta, ja pidempi säilytys edellyttää yleensä ehdokkaan päivitettyä suostumusta tai aktiivista yhteydenpitoa. Säilytysaika on kerrottava ehdokkaalle tietosuojaselosteessa.

Kuinka usein tallennetut haut kannattaa päivittää?

Aktiiviset toimeksiantokohtaiset haut kannattaa ajaa päivittäin tai viikoittain, ja yleiset profiilihaut tarkistetaan esimerkiksi neljännesvuosittain. IT-rekrytoinnissa teknologiat ja nimikkeet muuttuvat nopeasti, joten lausekkeiden synonyymit ja rajaukset vanhenevat muita aloja nopeammin.

Voiko tallennettuja hakuja jakaa koko tiimin kesken?

Voi, ja useimmiten se on suositeltavaa, koska jaettu haku säilyttää hakulogiikan toimistossa myös henkilöstövaihdosten yli. Jaetuille hauille kannattaa nimetä omistaja, joka vastaa lausekkeen päivittämisestä ja tulosten läpikäynnistä. Käyttöoikeudet on samalla rajattava niin, että tuloksia näkevät vain ne, joiden tehtävät sitä edellyttävät.

Lähteet

• Helsingin kaupunki: Make jobseeking easier with saved searches

• Fondia: Henkilötietojen kerääminen työnhakijasta rekrytoinnin yhteydessä

• Tietosuojavaltuutetun toimisto: Frequently asked questions about working life

• Dr. Datenschutz: Talentpool, datenschutzkonforme Aufnahme von Bewerbungen

• CNIL: Candidats, adoptez les 4 bons réflexes

• DSN Group: Bewerberdatenbank per Google Suche

• S-ryhmä: Työnhakijarekisteri

Suositukset

• Rekryjärjestelmän tietoturva: mitä vaatimuksia HR-päättäjän on tunnettava

• Rekrytointidatan säilytysajat: mitä lain mukaan tulee huomioida

• Työelämän tietosuojalaki: mitä HR saa käsitellä 2026?

• GDPR-suostumusten hallinta rekrytoinnissa: käytännön opas ATS:ään