Google Is Automation Too? Why Public-Sector OSINT Gets Blocked
Public-sector investigators are often allowed to search the internet manually, but blocked from using tools built to do that work properly.
That is not a legal strategy.
It is a failure to understand the work.
The short answer
Yes, public-sector organisations can use open-source intelligence.
They need a lawful purpose. They need proportionate methods. They need boundaries around collection, retention, sharing, security, verification and oversight.
What they do not need is a reflexive ban every time somebody says “automation,” “scraping,” “AI,” “social media” or “OSINT platform.”
Google is automated.
Bing is automated.
Maps are automated.
Reverse-image search is automated.
The real question is not whether a machine is involved.
The real question is what the tool does, what information it uses, what changes at scale and whether the organisation can explain and defend the method.
Google is allowed. The OSINT tool is not?
An investigator needs to establish whether a person, company, location or online account matters to a case.
They open Google. That is allowed.
They open Bing. Also allowed.
They search public websites, public registries, social-media posts, news archives, maps, images and company records. Nobody panics.
Then they ask to use an OSINT tool that searches, collects, compares, maps or monitors information from those same public sources.
Suddenly the answer is:
“No. You cannot use an automated tool.”
That answer needs work.
Google is an automated tool. A search engine does not send a team of analysts into the internet. It searches an index, ranks results, applies algorithms and returns information it thinks may be relevant.
So what is the actual concern?
Is it the source?
Is it the scale?
Is it the data being stored?
Is it a cross-border transfer?
Is it a vendor gaining access to case-related information?
Is it the use of a fake account?
Is it monitoring over time?
Is it the fact that nobody in the legal department understands what the tool does?
Those are different questions. They need different answers.
“Automation” is not an answer.
The manual method is not automatically safer
This is the part that gets missed.
A manual search is often treated as harmless because it looks familiar. An investigator opens a browser, types a name, checks a website, opens a social-media platform and moves on.
But what happens to those searches?
The search engine may receive the query. The platform may see the investigator’s IP address, browser fingerprint, cookies, session data and account activity. A logged-in browser may connect an investigator’s interest in a person, location, company or threat directly to an organisational account.
A public search can reveal a lot about the person doing the searching.
An investigator working manually may also copy information into notes, browser bookmarks, screenshots, spreadsheets, email threads and case folders. Ten people researching the same issue may each collect slightly different material in slightly different ways. One investigator may preserve the source and timestamp. Another may not. One may use an approved environment. Another may use a normal browser on a corporate network.
That is not always safer.
It is often just less visible.
A properly configured OSINT environment may be the more controlled option.
It can use dedicated research accounts. It can protect the investigator’s ordinary identity. It can limit access to authorised users. It can record what was searched, when it was searched and why. It can apply retention rules. It can preserve source material. It can reduce the temptation to move case-related work into personal spreadsheets, browser profiles or unapproved tools.
Then the organisation blocks that controlled environment because it is “automated.”
That is backwards.
The real question is not whether a person uses a browser or a purpose-built tool.
The question is:
Which method creates the least unnecessary exposure, the best evidence trail and the strongest safeguards for this specific task?
Sometimes the answer will be manual research.
Sometimes the answer will be an approved OSINT platform.
Sometimes the answer will be that the work should not be done at all.
But “manual equals safe” is not a serious conclusion.
Compare three risks, not one
Before blocking an OSINT capability, compare three risks:
The risk of using the proposed tool.
The risk of doing the work manually.
The risk of not doing the work at all.
Too many organisations only assess the first one.
They ask what could go wrong if an investigator uses a platform. They do not ask what is exposed through manual searching, what evidence gets lost through inconsistent workflows, what people may do when they are pushed toward workarounds, or what threat indicators remain unseen when nobody has the capability to find them.
That is a problem.
A legal department may identify genuine risks in a commercial OSINT platform. Perhaps searches are stored by the vendor. Perhaps the data leaves the country. Perhaps the platform combines information in a way that creates a profiling risk. Perhaps its terms of service do not support the intended use. Perhaps the organisation cannot explain how the tool produces a result.
Those are valid concerns.
But the analysis cannot stop there.
If the alternative is ten investigators using ordinary browsers, logged-in accounts, personal bookmarks, screenshots and separate spreadsheets, leadership needs to ask which option is actually more defensible.
If the alternative is that an investigator misses a public threat because the organisation has no approved way to search, verify and preserve the information at speed, that also belongs in the risk assessment.
Inaction is a choice.
Manual work is a choice.
A controlled platform is a choice.
Treat them like three options. Assess all three.
The problem starts with the wrong question
For 25 years, I worked for the Dutch government. I have seen this pattern more times than I can count.
An OSINT practitioner brings a capability to the table. A tool. A method. A workflow. A way to answer an intelligence question faster, more accurately or with better evidence.
Legal hears a new product name, a new platform, an unfamiliar technique or the word “automation.”
The answer becomes no.
Not after a proper assessment. Not after someone has asked what information is collected, what the investigator is trying to establish, whether the source is public, whether the result is retained, whether the tool can be configured, or whether the work is already being done manually.
Just no.
That approach does not make an organisation safer.
It makes it slower. It makes it less capable. It leaves investigators working with incomplete information while the people they are trying to understand, locate, protect against or investigate keep moving.
We live in a polarised world. Conflict, fraud, foreign interference, organised crime, disinformation, extremism, sanctions evasion, human trafficking, cybercrime and online exploitation do not wait for an internal legal meeting to finish.
Public-sector investigators need to be enabled to work.
That does not mean they should be allowed to do whatever they want. It means the people responsible for legal risk need to help build a way to do the work properly.
Stop calling every concern “legal”
An investigator asks to use a tool. Somebody says, “Legal will not allow it.”
But what does that actually mean?
If the concern is that the vendor stores data outside the country, that is a data-governance and supplier-risk issue.
If the concern is that the organisation does not know who can access the data, that is a security and procurement issue.
If the concern is that a platform’s terms prohibit a collection method, that is a contract and operational-risk issue.
If the concern is that the agency has no authority to conduct a particular type of monitoring, that is a legal-authority issue.
If the concern is that analysts are not trained to use the capability properly, that is a training, supervision and policy issue.
If the concern is that nobody understands the tool, say that.
Calling everything “legal” turns a solvable problem into a dead end.
It also makes legal departments look like the obstacle, even when the real problem sits elsewhere in the organisation.
A mature organisation separates the questions, assigns ownership and deals with each one.
Legal and operational leadership decide whether the organisation has authority for the use case.
Legal, privacy and operational leadership assess necessity and proportionality.
Security, procurement, privacy teams and the vendor assess data handling and access.
Technical teams and trained practitioners assess configuration and safety controls.
Legal, procurement and operations assess platform terms.
OSINT leadership ensures training, supervision, source evaluation and evidence standards.
That is what enablement looks like.
A legal no needs a receipt
If legal says no, that no needs a receipt.
Which law?
Which article?
Which internal policy?
Which part of the workflow?
Which risk cannot be mitigated?
Which condition would need to change before the answer becomes yes?
“We are not comfortable with it” is not legal advice.
“We do not know the tool” is not legal advice.
“It might be a problem” is not legal advice.
A legal department does not need to promise that every OSINT capability is safe. It does need to explain the decision in language that allows the organisation to act on it.
Every decision should record:
whether the capability is approved, approved with conditions or rejected;
the actual issue: legal authority, privacy, procurement, security, terms of service or training;
the precise rule, risk or missing safeguard;
which tool functions, sources and users are affected;
which conditions would allow a safe use case;
when the decision will be reviewed again.
This matters because undocumented “no” decisions become organisational folklore.
Someone hears that a tool was rejected three years ago. Nobody remembers why. The vendor has changed. The law has changed. The platform has changed. The organisation’s safeguards have changed.
But the answer remains no because that is what people have always heard.
That is not governance.
That is institutional memory without evidence.
Do not approve or ban a tool as one big object
“Can we use Tool X?” is usually the wrong question.
One platform may search public pages, enrich data, retain searches, create alerts, generate summaries, export reports, build relationship maps and connect to third-party datasets.
Those are different activities.
Legal should not approve or block the logo on the website. Legal should assess the functions.
A tool may be acceptable for public-source searching but not for persistent monitoring.
It may be acceptable for a named investigation but not for broad population-level collection.
It may be acceptable to use its search function but not its data-enrichment function.
It may be acceptable to generate a lead but not to use an automated score as the basis for action against a person.
Before a tool is approved, legal, privacy, security, procurement and practitioners should be able to answer:
Which sources does it use?
Does it access only public information or restricted information too?
Does it search, collect, enrich, infer, retain, export or monitor?
Where is data processed and stored?
Can high-risk functions be disabled?
Is the output a lead, evidence, intelligence assessment or decision input?
Can an analyst see and verify the original source?
What does the tool retain?
What is prohibited?
This gives everyone the same object to discuss.
It also stops a conversation about one feature from becoming a ban on an entire category of OSINT work.
A tool is not a method
A tool can have ten useful functions and ten functions that should never be used in a particular organisation.
A platform can be suitable for one case and completely unsuitable for another.
An automated search can be a sensible first step. Persistent monitoring of thousands of people may require a very different mandate, threshold and approval process.
Do not confuse a tool with a method.
A reverse-image search tool can help verify whether an image was taken where someone claims it was taken. It can also contribute to intrusive profiling if used without a proper question and proper limits.
A social-media monitoring platform can identify a public threat against a school, an airport, an elected official or a public event. It can also become a lazy way to collect large amounts of irrelevant information about people who have done nothing wrong.
A data-enrichment tool can help investigators connect a company, address, domain name and public corporate record. It can also create an inaccurate picture of a person if the output is treated as fact instead of a lead.
The tool is not the decision.
The intelligence question is the starting point.
“What can this platform collect?” is not an intelligence question.
“Which public information could help us establish whether this threat is credible?” is one.
Stop treating every OSINT request as red
If searching a company registry, verifying an image or checking a public username needs the same approval process as covert monitoring or biometric matching, the process is broken.
Risk-based governance means low-risk work moves quickly. Higher-risk work gets the scrutiny it deserves.
Green: routine, case-bound public research
Public websites, maps, registries, news, images and public posts. Enable this through documented standard rules.
Amber: expanded analysis with safeguards
Automated alerts, cross-source analysis, approved commercial tools and limited enrichment. Use defined safeguards, logging and retention limits.
Red: intrusive or persistent capabilities
Covert activity, restricted access, sensitive-data inference, biometrics, persistent profiling or large-scale monitoring. Require specific authority, senior approval and enhanced oversight.
This is not a perfect global model. The exact legal threshold will differ between countries, agencies and mandates.
It is still better than making every request a special case.
The European Data Protection Board has made clear that web scraping can involve personal-data processing when it includes collection, storage, organisation or retrieval. That does not ban web scraping. It means organisations need to think about legal basis, purpose limitation, transparency, data minimisation and accuracy. EDPB guidance on web scraping
That is where the discussion should be.
Not at “the tool is automated.”
Lawyers should observe the work before governing it
Lawyers should spend time with OSINT practitioners before they write rules for them.
Watch an analyst verify an image.
Watch them preserve a public post.
Watch them distinguish a lead from evidence.
Watch them document uncertainty.
Watch them explain why a username, a profile photo or a map pin proves far less than people think.
Watch them reject an attractive conclusion because the source cannot be verified.
Then discuss the risk.
You cannot govern a workflow properly if your understanding of that workflow starts and ends with a vendor brochure, a scary media article or the word “scraping.”
OSINT work is full of judgement calls.
A public post may be relevant, misleading, deleted, manipulated, old, misattributed or posted by someone pretending to be somebody else. An automated system may identify a pattern that turns out to be coincidence. A commercial database may connect records that belong to two different people with the same name.
Good practitioners know this.
They work with source evaluation, validation, timestamps, preservation, corroboration, confidence levels and clear language. They know that “consistent with” does not mean “proves.” They know that a lead is not evidence. They know that an OSINT result is often the beginning of a question, not the end of one.
Legal teams need to see that work.
Not because practitioners should be exempt from scrutiny.
Because scrutiny works better when it is based on the real workflow.
Publicly available does not mean free for all
Information being visible online does not mean an organisation can collect it without limits, retain it forever, combine it with everything else it owns, share it with external vendors, publish it or use it to make decisions about a person.
Public information can still be personal data. It can still be sensitive. It can still be false, manipulated, outdated or taken out of context.
The fact that a person posted something online does not automatically turn that person into a legitimate intelligence target.
The fact that a company database is searchable does not remove the need to ask why you are searching it.
The fact that a tool can collect at scale does not mean that it should.
That is where legal teams have an important job. But the job is not to stop at “no.”
The job is to identify the boundary.
For example:
You may search public sources manually or through an approved tool for a defined case purpose.
You may not bypass access controls, technical restrictions or a platform’s authentication process.
You may not use deceptive accounts without a specific mandate, documented necessity and approval.
You may use automated alerts for defined threat indicators, but not open-ended monitoring of a population.
You may retain relevant information for a defined period.
You may not build a permanent database of everyone who appeared in a public search result.
You may use AI-assisted analysis for leads, but an analyst must verify the result before it becomes an assessment or operational decision.
That is useful legal advice.
It gives investigators a route forward. It gives leadership oversight. It gives the organisation an audit trail. It also protects the public.
Government has more responsibility. That should lead to better rules.
Public-sector organisations are not commercial companies.
Their actions can affect someone’s liberty, reputation, employment, immigration status, benefits, safety or ability to move freely. They may have powers and access that a journalist, researcher or private company does not.
That means government needs stronger safeguards.
It does not mean government should be less capable than the threats it is trying to understand.
Across the world, the legal details differ. The United States has its constitutional framework, federal and state law, agency authorities, records requirements and procurement rules. Europe has data-protection law, human-rights principles and national rules for law enforcement, intelligence and public administration. Countries across Asia-Pacific have different approaches to privacy, public-sector data, data residency and national-security interests.
There is no global checkbox that says “OSINT: allowed” or “OSINT: prohibited.”
But the common questions are familiar:
What is the lawful purpose?
Is the activity necessary?
Is it proportionate?
What data is involved?
What changes when the work is automated?
Who has access?
Where is the data processed?
How long is it retained?
Can the result be verified?
Can the organisation explain the method if challenged?
The UN has repeatedly framed state privacy obligations around legality, legitimate purpose, necessity, proportionality and oversight. OHCHR: The Right to Privacy in the Digital Age
A legal department that understands those principles should be able to help an OSINT team design lawful workflows.
Journalists use the same internet
Journalists use reverse-image search, maps, satellite imagery, public records, company registries, social-media analysis, archive research, geolocation, chronolocation and digital verification.
They investigate war crimes, corruption, organised crime, sanctions evasion, misinformation, fraud and abuse.
Public-sector OSINT practitioners work with many of the same sources, tools and techniques.
That does not mean government can simply copy the legal position of a journalist. Journalists may have press-freedom protections and limited exemptions connected to public-interest publication. Those protections are not unlimited. ICO guidance on journalism and data-protection exemptions
But it does expose a strange contradiction.
A journalist can use an OSINT method to expose a threat, document abuse or verify public claims. A public-sector investigator may be told they cannot even assess whether the same method could help prevent harm.
That should make leadership pause.
Think about the incident review before it happens
After a major incident, no serious review will ask whether the tool was unfamiliar to legal.
It will ask whether public signals existed.
It will ask whether the organisation had the capability to find them.
It will ask whether trained investigators were prevented from using lawful, proportionate methods.
It will ask why information was available in public, but nobody saw the pattern.
“We were worried about automation” will not read well in that report.
OSINT will not prevent every incident. It will not turn public information into certainty. It will not replace human sources, criminal investigation, intelligence collection or professional judgement.
But an organisation that cannot find, verify, preserve and assess public signals is choosing to work with less information than it could have had.
That is also a risk decision.
Frequently asked questions
Can public-sector investigators use automated OSINT tools?
They can in many contexts, but the exact authority and limits depend on the jurisdiction, agency mandate, use case, data involved and safeguards. The correct approach is not a blanket yes or no. It is a documented assessment of purpose, necessity, proportionality, collection method, storage, sharing, retention, verification and oversight.
Is publicly available information free to collect and use?
No. Public availability does not remove privacy, data-protection, human-rights, platform, evidence-handling, security or fairness obligations. Public information may still be personal, sensitive, inaccurate or unsuitable to retain or combine at scale.
Are OSINT tools legally different from Google?
Sometimes. The difference is usually not that one is automated and the other is not. The difference may be scale, persistence, data enrichment, monitoring, vendor access, cross-border transfer, use of restricted sources, identity deception, biometrics or the way the output is used.
What should legal teams provide to OSINT practitioners?
A clear baseline for routine public-source research, a fast path for assessing new tools and methods, and a written explanation when a capability is rejected. The explanation should identify the authority, risk, affected function, required safeguard and review date.
A challenge for legal departments and leadership
Every legal department supporting public-sector OSINT should be able to deliver three things.
A clear baseline for routine public-source research.
A fast path for reviewing new tools and methods.
A written explanation when a capability is rejected, including the authority, risk and condition that prevented approval.
If the answer is no, investigators deserve to know whether the barrier is law, policy, vendor risk, technical uncertainty, lack of internal expertise or a missing safeguard.
“No” is not a framework.
Public-sector OSINT does not need fewer rules.
It needs rules written by people who understand the work well enough to enable it.
Comments