Why personal AI agent companies need to prepare for new EU regulations in January 2027

Ask a personal AI agent to book a hotel, and the ideal experience is almost boring. It finds a room, checks the cancellation policy, enters your details, and comes back with a confirmation. All the tedious clicking disappears. At last, someone else can dismiss the invitation to join the hotel’s loyalty program.

But so does your opportunity to inspect the website taking your money. The agent may have read every word on the booking page without establishing which business operates it. A convincing logo and a reassuring paragraph about security are easy enough to copy. The agent could complete the booking in thirty seconds and leave you three weeks of disputing the charge.

Companies building these agents should treat website identity as part of the product. They should also pay attention to an approaching European regulatory milestone: January 6, 2027, when new reference standards for qualified website authentication certificates begin to apply.

Customers delegating a purchase will depend on the agent to check whom they are paying.

What Europe is asking browsers to do

Qualified Website Authentication Certificates, or QWACs, connect websites with independently verified identity information. Their issuers operate within the EU’s supervised framework for qualified trust services. A website can therefore offer evidence of its operator’s identity that goes beyond whatever it chooses to write on its About page.

Article 45 of eIDAS, amended in 2024, requires covered browser providers to recognize compliant QWACs and display certified identity information in a user-friendly way. Commission Implementing Regulation (EU) 2025/2527 supplies reference standards and applies from January 6, 2027.

The browser obligations already exist. January brings the reference standards into application; an AI company’s responsibilities depend on whether its service falls within the rules.

The interesting question is which agent companies are providing a browsing service.

Browsing through an agent

The referenced ETSI standard defines a browser by its functions: retrieving, rendering, and interacting with websites for a user. That functional definition raises questions for companies whose customers browse through a chat window.

Consider our hotel-booking agent. Somewhere behind the chat window, software visits websites and fills out forms on the customer’s behalf. The customer sees a conversation instead of a row of tabs, but the browsing still happens.

My view is that companies offering these interactive services have a strong reason to assess whether they fall within the browser obligations. The scope of any particular service requires legal assessment. A service acting for a person making a purchase presents a different case from an internal testing tool or a general indexing crawler.

The review also needs to establish the service’s connection to the EU and which company provides the browsing experience. Article 45 includes a limited exception to its support and interoperability requirement for qualifying microenterprises and small enterprises during their first five years of providing browsing services. That is narrower than a general startup exemption from all browser duties.

When a customer’s agent visits a website, who is responsible for checking and showing its identity? “Probably our browser vendor” is the sort of answer that can survive several planning meetings before anyone asks the vendor.

Keep the identity attached to the visit

A browsing service might return a URL, a screenshot, and the text of a page. I would add the verified identity of the website operator to that result. An agent should be able to distinguish the company a website claims to represent from the identity its browsing software has actually checked.

Suppose a traveler asks to book directly with a particular hotel. If the verified operator is an unfamiliar travel agency, the agent has a reason to pause and explain the difference. The agency may be perfectly legitimate, but the distinction could change the cancellation terms, the price, or whom the traveler must call when something goes wrong.

I would design the API to keep the browser’s verification result separate from the page’s own claims. Otherwise, a website could write “verified” next to its name and let the model confuse that assertion with an independent check. Providers would need to assess whether this design meets their legal obligations.

The result also needs to belong to the visit that produced it. Redirecting to another website should not carry the previous company’s identity along for the ride. A missing certificate, a failed check, and a check that has not finished should remain distinguishable. Otherwise the integration can turn uncertainty into a confident-looking badge, a category of output AI products already supply in abundance.

Hosted browsers and proxies make this worth testing carefully. Some intermediaries replace the website’s encrypted connection with their own. In the separate-certificate QWAC model, the identity is bound to the website’s connection certificate; substituting an unrelated certificate breaks that verification path. Teams need to preserve the original evidence or have a trusted component verify it and securely pass the result along.

The customer still needs to see it

Passing identity information to the model is only part of the work. The display requirement also calls for an interface through which the customer can inspect it.

The European Commission’s guidance gives browser providers flexibility in how they present certified information. For an agent product, I would make the business identity accessible alongside a purchase confirmation or a cited source. The user should be able to inspect who is involved without opening a technical certificate viewer.

The interface should explain what was checked: the identity behind the website. An agent would still need other evidence to assess whether a hotel room exists, a merchant will issue a refund, or an article is accurate.

What founders should do before January

Start by assigning responsibility for the entire path, from visiting a website to showing the result to the customer. Ask counsel to assess the service’s scope under the rules. Ask the browsing vendor what it verifies, what it returns, and what the downstream agent must do. Then test the browser build and configuration actually running in production to establish which checks are enabled.

The tests should include expired certificates, failed verification, redirects, and visits with no QWAC. They should also establish what a person sees when any of those things happen. Test consecutive visits, too: an integration could pass its first check and then show the same company’s identity after the customer moves to another website.

An agent company asking customers to delegate purchases and other consequential decisions needs to explain how it evaluates the parties involved. Independent identity evidence gives it something more substantial than the model’s impression of a well-designed website.

Personal agents promise to spare people the work of navigating the web. The companies building them will inherit some of that work, including the less glamorous job of checking who is asking for the customer’s money. Doing that job well will be part of earning the trust on which the whole business depends.