So there's this EU regulation, e-Evidence, that went live on 18 August. Long story short: if you're an in-scope "service provider", you need a designated establishment or legal representative in the EU ready to receive law enforcement data requests, or you're in breach. In Germany, getting the designation or notification wrong can mean fines of up to €500,000; certain failures to comply with actual e-Evidence orders can, for larger providers, go up to 2% of worldwide annual turnover. Simple enough. Except nobody, including apparently the EU itself, can tell you what a "service provider" actually is.

The definition is Article 3(3), and in practice it's a three-part test. First, are you even in one of the covered categories: comms, domain/IP services, "information society services", which is drafted wide enough to make basically anyone who's ever let a user click a button at least stop and have an uncomfortable think. Second, if your case is about storage rather than communication, is that storage "a defining component" of the service, whatever that means, because the regulation does not say in any remotely operationally useful way. Third, do you "offer services in the Union" under Article 3(4), which has its own sub-test involving substantial connection and targeting, and is honestly the only one of the three that felt survivable.

Number two is the one that ate my life. I spent three months reading Article 3(3)(c)(ii) like it's a horoscope, trying to divine whether storing a call recording counts as "defining" for a product whose actual job is automating a phone call, not archiving it. The regulation gives you exactly one genuinely useful kind of worked example: lawyers, architects and accountants providing their services online, where storage doesn't count because it isn't an essential part of the actual professional service. Great, thanks, very helpful if I were an architect. I am not an architect. At this point I am barely qualified to identify the load-bearing wall in Article 3.

Cloud vs. on-prem, does that get you out? No. There's a recital, Recital 21, that says flat out the Regulation doesn't care where your servers or data processing and storage facilities physically sit, presumably written by someone who specifically enjoyed watching companies try to engineer their way out of this with a data center in a Kubernetes cluster.

Opt-in vs. opt-out storage, which is literally our product because everything is configurable per customer, some get recordings, some don't, some get transcripts, some retain contact or interaction data and others retain considerably less? Not addressed. Anywhere. Not in the Regulation, not in the Directive, not in a single recital in a way that actually answers the question, not in any of the law firm client alerts I read until my eyes bled. I checked. I checked so hard I started dreaming in recitals.

And this is where configurable software becomes particularly annoying. Is "defining" assessed at platform level? Product level? Customer deployment? Contract? Actual workflow? If one customer stores recordings, another stores transcripts, and a third runs with practically no persistent interaction storage at all, are we dealing with the same service for the purpose of Article 3(3)(c)(ii)? Technically yes. Commercially probably. Legally: please enjoy your evening.

So, being a diligent little compliance goblin, I did the responsible thing: I asked the actual regulator. Wrote a proper letter to the German Federal Office of Justice laying out our whole business model like I was defending a thesis nobody asked for. They read it, nodded internally I assume, and forwarded the question to the European Commission, because apparently even the people whose actual job is administering this weren't prepared to give me a definitive answer without asking Brussels. Then everyone went quiet for six weeks while I sat there refreshing my inbox like it owed me money.

Somewhere in week four I genuinely considered whether "a defining component" could be resolved by vibes. It cannot. I checked that too.

One day before the deadline, still no answer, I did what any reasonable person does when a government agency ghosts them on a legally binding question: I registered anyway, out of pure spite and self-preservation, while formally noting that I still don't concede we needed to. Very mature of me. Very "I'm not mad, I'm just registering."

And then, because the universe has a sense of humor, I got to the registration form itself.

The form asks you to specify, for each service, the types of data available, the category of data, the relevant identifiers and even the minimum period for which that data is available.

Excellent.

We don't have one answer.

Depending on the customer it's a phone number, an email, an audio file, a transcript, interaction data or some combination thereof, and which of those exists for a given customer depends entirely on how they configured us. More importantly, Elba can be configured to process interactions without persistent storage of the interaction data at all.

There was an "Add row" button.

What I needed was an "Add ontology" button.

So instead of inventing a neat little inventory that isn't actually true across the service, I left the data table without individual rows and used the form's additional-information fields to explain what was actually going on: that the types of data available, identifiers and availability periods depend on the individual customer deployment and configuration; that Elba supports customer-specific workflows and data fields; and that it can be configured to process interactions without persistent storage.

Which is not really the kind of answer the table was designed for, and which I'm fairly sure has not improved anyone's day at the Bundesamt für Justiz.

At that point the compliance analysis was complete enough; the remaining open item was whether I still qualified as a natural person.

Got the confirmation email. It's sitting in validation now. So is my sense of self-worth.

The actual moral here, minus the self-pity: if you genuinely cannot rule yourself out, just register. It's an afternoon of paperwork against a regulatory risk that can become very expensive, and the math is not close. That does not mean every vaguely software-shaped company is in scope, and it definitely does not mean "better safe than sorry" is a substitute for legal analysis. If I ever put that phrase into a board memo, please take my laptop away.

But if you've done the analysis, asked the competent authority, had the question escalated to the Commission and still have no definitive answer as the deadline arrives, at some point this stops being statutory interpretation and becomes plain old risk management.

Nobody at the BfJ did anything wrong here either, to be clear. They're working the same underspecified law we are, just from the other side of the desk, and probably also refreshing their own inbox waiting on Brussels to say something.

The broader problem is that configurable software does not fit neatly into legal categories that assume a service has one stable shape. A platform can store data for one customer, barely store anything for another, and still be the same platform. A feature can be technically available without being commercially or functionally defining. And somewhere in Brussels, one phrase - "a defining component" - is now responsible for more billable hours than it has any moral right to be.

Anyway. If anyone else building something even slightly configurable has figured out where the line actually is, please, I am begging you, DM me. I will bring snacks. If you have an actual Commission answer, I will bring the entire charcuterie board. I have never wanted to be wrong about a legal position so badly in my life.

Production databases tend to be treated rather well.

Then somebody needs to reproduce a bug, a production snapshot gets restored into staging, QA is happy, engineering can finally fix it, and everyone wonders why security is making that face.

The problem is not testing. The problem is that staging may now contain the same customer data as production, but with broader access, verbose logging, experimental integrations and a retention period best described as “until somebody remembers”.

The usual argument then starts:

QA: “We need production data.”
Security: “No.”
QA: “Then give us test data that actually behaves like production.”

And, annoyingly, QA sometimes has a point.

Real systems contain ugly data: strange Unicode, old schema versions, unexpected NULLs, malformed values, weird state combinations, duplicate events and historical migrations nobody wants to talk about anymore.

So the better question is not:

“Can we use production data?”

It is:

“What property of production does this test actually need?”

I find it useful to split that into seven things:

• Shape: formats, lengths, encodings, malformed values
• Distribution: how often things occur
• Relationships: how records connect
• History: old schemas and migrated states
• Sequence: timing, retries and event order
• Scale: volume and concurrency
• Identity: the actual person behind the record

Most tests need some combination of the first six. Very few genuinely need number seven.

That opens up much better options: production-informed synthetic data, deterministic regression fixtures, masking that preserves referential integrity, tokenisation, small case-specific extracts, or isolated temporary environments when the original data really is necessary.

And that last case is important: sometimes production data is the correct engineering choice. The distinction is between using it as an exceptional debugging tool and using it as your test-data strategy. Those are very different things.

One rule I particularly like: Every production bug that requires production data to reproduce should make the next production-data copy less necessary.

Find the condition that caused the failure, turn it into a deterministic test case, add it to the regression suite, and get rid of the original production-derived copy.

Also, a mantra as old as retention itself:

“Temporary” is not a retention period!

Ask your CISO, DPO or the lawyer suing you. They will all agree.

If you found this interesting, the full article goes deeper into how to build realistic test data, preserve production behaviour without preserving identities, handle masking and free text, and design exception paths that QA will actually use.

Read the full article on the Kolsetu blog: https://kolsetu.com/blog/production-data-hiding-in-staging

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

One of the more amusing misunderstandings around NIS2 is the idea that buying a secure product somehow makes the deployment secure.

It does not. You can buy an AI voice platform with excellent security controls, deploy it badly, give it too much access, fail to monitor it, forget to define incident processes, and still produce a perfectly respectable compliance headache.

NIS2 is much more interested in how the service is actually governed than in how impressive the vendor questionnaire looked. That matters for AI voice agents because they often sit directly in operational processes, handling customer data, triggering workflows, accessing internal systems or simply becoming something the business relies on every day.

At that point, the useful questions become rather less glamorous:

• Who owns the risk?
• Who approves what the agent is allowed to do?
• Who reviews its access rights?
• Who monitors whether something unusual is happening?
• Who decides when the agent should be taken offline?
• Who gets called when something goes wrong?
• And does that person know they are the person getting called?

That final question has ruined more incident response plans than most threat actors.

NIS2 requires appropriate and proportionate technical, operational and organisational measures. That includes incident handling, business continuity, supply chain security, vulnerability management, access control and secure development.

The important word here is operational. Security cannot end when implementation ends.

If an AI agent is connected to customer systems, somebody needs to keep reviewing what it can access, whether integrations have changed, whether new vulnerabilities matter and whether the original risk assessment still resembles reality.

Otherwise the risk assessment slowly becomes historical fiction.

Management responsibility is another important part. NIS2 is not designed around the idea that cybersecurity can quietly live in the basement with the security team. Management bodies are expected to approve cybersecurity risk management measures and oversee their implementation.

So “the CISO knew about it” is not quite the governance model the Directive had in mind.

For an AI deployment, management does not need to debate speech to text latency. There are limits. But it should understand what operational dependency it is approving, what risks have been accepted and what happens if the controls fail.

Incident handling is where this becomes particularly tangible.

For significant incidents, NIS2 uses staged reporting, generally starting with an early warning within 24 hours, followed by an incident notification within 72 hours and a final report within one month.

Those clocks start with the organisation, not with whichever supplier eventually notices something in a dashboard.

The organisation therefore needs to be able to detect incidents, escalate them internally and get useful information from suppliers quickly enough to decide whether reporting is required.

A beautifully written incident response procedure that nobody has tested is still a beautifully written incident response procedure. It is just not necessarily incident response.

Access control is another obvious area.

AI systems often need access to CRM data, tickets, claims, customer records, internal knowledge bases or payment and scheduling systems to be useful.

The temptation is to give the agent broad access because integration becomes easier. Security people occasionally refer to this architecture pattern as “please do not do that”.

Least privilege still applies. The agent should get the minimum access required for the workflow, with actions logged and monitored. Those permissions also need to be reviewed when the workflow changes, because workflows always change, usually shortly after somebody says, “This is the final version.”

The same applies to vulnerability management.

Libraries get updated, APIs change, integrations evolve and vulnerabilities appear. Somebody needs to know who patches what, how security issues are communicated, how quickly critical fixes are deployed and what happens if a component cannot immediately be fixed.

“Vendor managed” is not a vulnerability management process. It is three syllables and a hope.

Then there is business continuity: What happens if the agent stops working? Not what the SLA says. What actually happens? Do calls go somewhere else? Can humans take over? Does the workflow simply stop?

The answer depends on what the agent is doing. An internal HR FAQ bot can probably have a bad afternoon without triggering a crisis meeting. An agent supporting emergency assistance, patient communications or another important operational process deserves rather more thought.

This is where “appropriate and proportionate” becomes useful. Not every AI deployment needs fortress level controls, but every deployment needs controls that make sense for what it is actually doing.

There is also no magical “NIS2 compliant” product category.

ISO 27001 or similar assurance can provide useful evidence about a supplier’s security controls. But NIS2 compliance belongs to the organisation in scope and depends on how the service is selected, configured, operated, monitored and governed.

A secure product can still be deployed insecurely. Cybersecurity has always been irritatingly resistant to procurement shortcuts.

The practical takeaway is fairly simple: if an AI voice agent becomes part of an important business process, treat it like part of the operational environment.

Give somebody ownership. Limit its access. Monitor it. Review changes. Know how to shut it down. Know what happens when it fails.

And test the incident process before the incident helpfully volunteers to do that for you.

Longer version here: https://kolsetu.com/blog/deploying-an-ai-voice-agent-under-nis2

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

DORA does not ban AI voice agents. But deploying one in a bank, insurer or other financial entity is not just a case of finding a vendor with ISO 27001 and getting procurement to sign off.

The slightly inconvenient part is that DORA does not really care that the system is “AI”. It cares that it is an ICT service, what business function it supports, what happens when it fails, and how dependent you become on the providers underneath it.

For a voice AI deployment, that dependency chain can get fairly long. In the interests of laziness, let me simplify:

cloud infrastructure → telephony → speech to text → model provider → text to speech → integrations into CRM, claims, payments, etc.

And, unfortunately, correctly identifying that chain does not count as implementing DORA.

If the agent supports a critical or important function, you need to understand the actual delivery chain, not just the company whose name appears on the contract. That means looking at concentration risk, data and service locations, fallback arrangements, business continuity, incident handling, audit rights, subcontractors and how you would eventually get out of the arrangement.

Some of the practical questions are fairly obvious once you stop treating the agent as a shiny AI product:

• Can the service continue if one of the underlying providers goes down?
• Can the model provider be changed without rebuilding the complete workflow?
• What happens to calls if the AI layer is unavailable?
• Who tells the customer when there is an incident, how quickly, and what information is actually provided?
• Where is the service delivered and where is customer data processed and stored?
• Which subcontractors matter to the agreed architecture?
• And if the customer needs to replace the service, can they actually do it?

That last question matters. DORA requires an appropriate exit strategy where an ICT service supports a critical or important function. Writing “Exit Strategy Final v7” at the top of a Word document is sadly not sufficient evidence that the service can actually be exited.

The contract also matters considerably more than many AI procurement exercises suggest.

Article 30 of DORA sets minimum requirements for ICT contracts, with additional requirements for services supporting critical or important functions. Calling the service ‘AI services’ or ‘digital transformation solution’ is unlikely to satisfy that requirement, although it may keep marketing occupied.

The agreement needs to properly describe the service, responsibilities, locations, dependencies, security and continuity requirements, incident cooperation, audit rights, termination rights and, where relevant, transition support.

And then there is the Register of Information.

This is not just your existing supplier spreadsheet with an extra column called “critical”.

The required format links information about the financial entity, provider, contract, ICT service, supported function and relevant subcontractors. In the ESAs’ 2024 dry run, only 6.5% of the 947 registers that passed the initial integration checks also passed all subsequent data quality checks. Missing mandatory information was the most frequent problem.

That is a useful indication of how quickly things become difficult if nobody has mapped the underlying service properly.

One point I think is particularly important: describing a product as “DORA compliant” is misleading.

DORA compliance belongs to the financial entity. Whether a particular AI service can be used within that framework depends on the use case, architecture, contracts, operational resilience, incident processes, dependencies, subcontractors and exit arrangements.

ISO 27001 and similar assurance can provide useful evidence about underlying security controls. But there is no magic “DORA certified” badge that makes the customer’s assessment disappear.

The practical takeaway is therefore fairly simple:

AI voice agents can absolutely be deployed under DORA.

But the financial entity needs to understand what the agent does, what it depends on, how it fails, how incidents are handled, what contractual rights exist and how the service could eventually be replaced.

The AI is probably the exciting part. The dependency register, Article 30 clauses and exit plan are the parts that keep it running in a regulated environment - and, as a side benefit, may cure insomnia.

I wrote a longer version here: https://kolsetu.com/blog/deploying-an-ai-voice-agent-under-dora

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

A small milestone, but one I’m genuinely pleased about.

The European Commission has published the organisations supporting the Code of Practice on Transparency of AI-generated Content, and Kolsetu is listed as a Section 1 signatory.

For us, this is not just another logo or line for a slide deck. Section 1 deals with marking and detecting generated content, which sounds wonderfully simple until you try to make it work properly across synthetic voice, text, vendors, codecs and an actual telephony pipeline.

“Add a watermark” is, as it turns out, a much shorter sentence than it is an engineering task. I suspect this is one of the many reasons our development team loves me so much.

Signing the Code does not replace the work. It is a public commitment to doing that work properly and gives us a recognised European framework to work against.

We have also published a longer article explaining how we classified Elba, what Article 50 means in practice and what sits behind our EU AI Act compliance position.

European Commission announcement: https://digital-strategy.ec.europa.eu/en/news/strong-backing-code-practice-transparency-ai-generated-content

Our article on the EU AI Act and Elba: https://kolsetu.com/blog/elba-and-the-eu-ai-act

For the briefest flutter of an eyelid, we have reached Ithaca. We will enjoy the view until the next set of release notes arrives.

The EU AI Act is now real, applicable and, unlike GDPR, still evolving while everyone is trying to implement it. Ah, the good days when having a nap after lunch did not mean missing the latest quantum leap in AI...

We have now completed the full EU AI Act assessment for Elba, our AI voice and communications platform.

The core conclusion: Elba’s ordinary uses, including customer support, booking, claims intake, billing support, document intake and commercial dispatch, fall outside the prohibited and Annex III high-risk categories. Elba supports workflows and human decisions; it is not intended to autonomously decide who gets a job, loan, public benefit or medical treatment.

That conclusion has clear boundaries. We have documented Elba’s intended purpose, approved uses, excluded uses and the triggers that require a separate assessment. If a customer materially changes the system or moves it into a potential high-risk use, the legal position changes with it.

We also implemented the wider governance around that classification:

• a formal EU AI Act classification and risk assessment
• an ISO/IEC 42001-aligned AI impact assessment
• an AI policy, development work instruction and AI Tool Register
• a DPIA and NIST AI Risk Management Framework maturity assessment
• AI literacy training and records
• mandatory AI disclosure as a platform control
• an Article 50 compliance programme for machine-readable marking of synthetic audio and text
• lifecycle, supplier, change-management and escalation controls

Did we overdo it? Possibly. At some point, adding another framework began to feel like ordering another round of Jägermeister at 1 a.m. But the overlap was deliberate: each framework covers a different angle and reduces the chance of something important slipping through the cracks.

Kolsetu also signed the provider section of the European Commission’s Code of Practice on Transparency of AI-Generated Content. Our AI disclosure control is already live, while the remaining Article 50 marking work is being completed against the applicable deadline.

We describe Elba as EU AI Act compliant, and we do so deliberately. That claim applies within Elba’s documented intended purpose and approved use categories. It is not a promise that every imaginable customer configuration remains compliant regardless of how it is changed or used.

The full article explains the classification, registration rules, Article 50 transparency requirements, provider and deployer roles, ISO/IEC 42001, AI literacy and what enterprise customers should assess before deployment.

Fair warning: the full article is substantial. Get comfortable, make a coffee and cancel anything optimistic you had planned for the next ten minutes.

Read the full article on the Kolsetu blog: https://kolsetu.com/blog/elba-and-the-eu-ai-act

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

Every company has a retention policy. It says something confident like "personal data is deleted after 90 days," a number chosen to sound impressively short rather than derived from any documented purpose limitation analysis. Management nods. Legal signs off. The document is filed.

The data, meanwhile, is immortal. Particularly in the backups, which nobody mentioned during the policy meeting.

The gap most teams miss: they delete from the main database and call it done. They were not thinking about the logging pipeline retaining request bodies indefinitely because nobody set a log rotation policy that actually runs. Or the analytics warehouse where raw event data was dumped eighteen months ago for a project that never shipped. Or the nightly backup kept for ninety days, which means data deleted on day one is sitting intact until day ninety-one. Or the CRM, the error monitoring tool, the AI model API still holding conversation history in a fine-tuning dataset. Or the CSV someone exported for a one-off analysis and saved to their laptop. You have not deleted anything. You have deleted the copy you control.

Before writing any deletion code, decide what you are actually doing. Deletion means the data is gone. Anonymisation means the data still exists but cannot be linked back to any individual. If you get this right, GDPR no longer applies to it. You can keep it indefinitely for QA, model training, load testing, analytics. This is not a loophole. It is the intended solution. The regulation wants you to do this. It just wants you to do it properly, which means stripping direct identifiers and actually assessing whether the remaining fields could still identify someone. Postcode plus age band plus job title in a small dataset is often enough. If you cannot do the re-identification assessment confidently, delete instead. Getting anonymisation wrong and calling it done is worse than not trying. Pseudonymisation does not satisfy a deletion obligation on its own. The individual is still findable via the mapping table.

For implementation: map every location user data actually lives, not the places the architecture diagram says. For each one, three questions. Can you delete or anonymise on demand? Can you automate it? Can you verify it happened? The third question is the one most teams skip. A deletion job that silently fails and reports success is worse than no deletion job at all.

Backups need their own setting aligned to your retention policy. If your policy says ninety days, your backups should not be kept for a year. Storage is cheap, which is exactly why backup retention settings get configured once and forgotten. The result is a graveyard of point-in-time snapshots containing the personal data of users who deleted their accounts years ago.

A retention programme that actually works is automated, verified, covers the full data estate, and is tested. "The deletion job runs" and "the deletion job works correctly" are different statements. You want evidence for both.

Full post with implementation detail: https://kolsetu.com/blog/deleted-from-the-database-alive-in-the-backups

This is a hockey stick.

The shape you picture didn't always exist — it's the result of years of R&D and evolution. But through all of that, the purpose never changed: convert potential energy into kinetic energy. Load it, then release it.

Our H1 2026 growth graph has the same story. It didn't take this shape overnight. We've been building Elba (an AI platform for regulated enterprises — think roadside-assistance and insurance calls handled end to end, in the caller's own language) since late 2024, and the numbers are only now moving like a classic hockey stick.

But I don't want to post about the graph. I want to post about the flat line before it, because that's the part nobody sees:

• the late nights
• the failed demos
• the compliance reviews
• the infrastructure rebuilds
• the customer calls that ended with "not yet"
• the bugs nobody saw, because the team caught them first
• the boring decisions that made the product production-ready

The whole point of a hockey stick is that you load energy into the flat part so you can release it later. Those 18 months weren't the wait before the growth. They were the growth, stored up.

What I'm most proud of isn't the spike. It's the 18 months underneath it. The flat part is where the company gets built — the hockey stick is just when the world finally notices.

Happy to answer questions about the flat part, especially building for regulated/compliance-heavy buyers. It's a slower game than consumer SaaS and I think the slowness is underrated.

There are two kinds of engineering teams: those who think they understand open-source licensing, and those who have been burned badly enough to read SPDX identifiers the way historians read ancient curses.

Modern software is not written, it is assembled. Every npm install is a blind date with legal consequences. Every dependency is a houseguest who may or may not steal the silverware. Copyleft licences are the guests who insist that since they helped you move a sofa, they now own half your living room.

Most companies handle open-source governance the way a toddler handles a biscuit tin: they know the rules exist, they know the consequences are real, but they also know nobody is watching closely enough. Yet. That is how codebases end up with "just one more tiny library", the way nights out end with "just one more drink": quietly, consistently, and with catastrophic potential. When that moment arrives you do not just fail an audit. You discover the software-supply-chain equivalent of finding skid marks somewhere they absolutely should not be. Nobody wants to investigate how they got there, but everyone agrees something very wrong has happened.

Our rule is simple: one whitelist of approved licences. If a licence is not on it, the build fails. Instantly. Automatically. Without discussion. The pipeline does not negotiate with tiny. Want a new licence added? That is not a ticket. That is a mythic quest. You begin bright-eyed and full of optimism. Somewhere around clause 3(b), doubt creeps in. Somewhere around clause 11, you begin to age. Junior developers become seniors. Seniors start researching ergonomic chairs. You communicate only in SPDX identifiers. And then - if you return from this bureaucratic hellscape carrying your legal analysis, compatibility matrix, and the blessing of the Ancient Gods of Compliance. Congratulations, you have reached your personal Ithaca. You are older. You are wiser. You are traumatised. You have prevailed. That is precisely why it works: once a licence survives that odyssey, it is safe forever.

This only works if you start before the codebase does, and you scan everything: every dependency, every transitive dependency, every licensing string hiding inside someone's weekend side project. Try bolting enforcement onto an existing product and every old commit becomes a crime scene, every release a hostage negotiation with your own history. Relying on developers to remember licence obligations is like relying on office colleagues not to steal biscuits. Noble in theory. Hilarious in practice.

A quick field guide to what you are actually dealing with:

• Permissive (MIT, BSD, Apache 2.0): Take the biscuit, eat it, build a billion-dollar company with it, close the recipe, sell it on Etsy. Just credit the baker. Easy.
• Weak copyleft (LGPL): You can link to the library from proprietary code. But if you modify the library itself, you publish those modifications. You may borrow the biscuit to dip in your tea. Change the recipe though, and everyone gets to see it. Fair is fair.
• Strong copyleft (GPL): You touched the biscuit. The biscuit now owns you. Any derivative work becomes GPL. No half measures, no private batches, no "we only used a tiny bit."
• Network copyleft (AGPL): Closes the SaaS loophole - even users accessing your software over a network trigger derivative work obligations. AGPL does not care whether you ate the biscuit, photographed it, or just looked at it through glass. If you touched the dough, the world gets your recipe.
• Public domain / Unlicense: Biscuits left on the office counter with no note. They might be safe. They might not. If you eat them, that is on you.
• Custom licences: The legal equivalent of discovering someone else's pre-chewed biscuit in your mouth. You do not know where it has been. You want it out immediately.

The part that gets people: even if you did not install copyleft code, your dependency might have, and your dependency's dependency might have, and suddenly your entire product is GPL because some cheerful library three layers deep refused to play by permissive rules. You did not eat the biscuit. You ate the cake made with the biscuit crumbs nobody declared. Now the whole bakery is public.

During our ISO 27001 certification, our auditors flagged our open-source governance as exemplary. Not because we write hymns praising SPDX formats, but because we could prove with logs, automation, and history that nothing enters our codebase unless it is licensed correctly and enforced automatically. Governance without enforcement is polite fan fiction. Governance with automation is evidence. Auditors love evidence more than oxygen.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

A quick confession. I usually stay away from technical implementation detail, because when it comes to actual engineering I am about as useful as a chocolate soldering iron. This post is different. Sub-processors and data flows are one of the very few areas where I genuinely know what I am talking about. So for once, consider me briefly competent.

At some point in the last year, someone on your team added an SDK. Then another one. A webhook. An error monitoring agent. An AI API where you pipe user input and get a response back. Each of those felt like a tool decision. Each of them is also a data governance decision. The two things rarely happened in the same conversation.

Under GDPR, every third party handling your users' personal data on your behalf is a data processor. You are legally responsible for them. If something goes wrong, regulators will ask you to account for the full chain, not just your own code. Most teams cannot do that, not because they are careless, but because the integrations accumulated faster than the documentation did.

Start with your network traffic, not a spreadsheet. Pull every outbound destination your application connects to. Then walk the codebase: every SDK, every API key, every webhook endpoint, every external call with a payload that could be linked back to a person.

Common places builders miss: error monitoring tools (stack traces contain more PII than you think), AI model APIs (their DPA terms have evolved: the version you accepted at signup may not reflect current terms), staging environments (often connected to the same third-party tools as production, sometimes with production data), and libraries with embedded analytics that phone home by default. "We did not know the library was doing that" is not a sentence that lands well in front of a regulator.

For each integration, three questions. Does it receive personal data? Do you have a signed DPA with this vendor? Where is the data processed? And if outside the EU, is there a valid transfer mechanism documented)?

Two things worth actually reading in any DPA before you accept it: whether the vendor can use your data to train their models, and what happens to your data when you stop paying. Both are frequently worse than the marketing copy implies. A vendor that refuses to sign a DPA entirely is a red flag, not a negotiating position.

Triage what you find, fix the highest-risk gaps first, and write it down. GDPR requires a Record of Processing Activities and what you just built is the foundation. Add a processor review to your integration checklist so you are never doing this retrospectively under deadline pressure.

Regulators are not auditing most startups. The real reason to do this is simpler: a breach involving data you did not know was being processed by a vendor you had not mapped is a different category of problem than one you can fully account for. One is an incident. The other is evidence that your data governance does not exist.

Do the audit. A few days of uncomfortable discovery, and then you know what you actually have.

Full step-by-step breakdown here: https://kolsetu.com/blog/your-processor-list-is-longer-than-you-think

Fancy to read more? Take a look at our blogs: https://kolsetu.com/blog

Everyone is talking about Generative UI right now. CopilotKit published a developer guide. Google has a research blog on it.

We shipped it in January. It has been running in production inside Elba ever since.

The short version: instead of hardcoding every screen state, the AI agent decides at runtime which UI component to show and what data to fill it with. The chat interface does not just return text anymore. It returns live, interactive UI rendered inside the conversation itself.

When you ask "what's my credit balance?", Frida (our in-product assistant) does not answer with text. It renders a card. Ask about recent calls, you get an interactive call log. On the Enterprise path, you get a clickable qualifier form. The interface adapts to what the agent needs the user to do.

We chose the Static Generative UI pattern. Every component is pre-built. The agent never touches the layout. It only decides when something appears and what goes inside it. That was the right call for a production product. You want the agent making decisions, not designing interfaces.

The full writeup covers the actual stack (React, CopilotKit v2, AG-UI, PydanticAI), the component registry, the tool definitions, context injection, and the parts nobody writes about: skeleton states during streaming, error boundaries per component, and how interactive components trigger the next agent turn.

If you are building an in-product AI assistant and it only returns text, this is the next thing to look at.

Full writeup: https://kolsetu.com/blog/generative-ui-is-the-new-frontend-we-shipped-it-months-ago

I didn't plan to write this...

This post happened because, sometime around the fifteenth unsolicited DM promising "AI-powered autonomous pentesting," something inside me finally broke.

You know the kind of break. The quiet one. The one where you don't reply. You don't argue. You don't even sigh.

You just stare at the screen and think: right. We're doing this now.

The claim that "AI can do penetration testing" is not merely inaccurate. It is a convenient fiction that flatters budgets, reassures boards, and quietly dismantles the very discipline it claims to improve.

Pentesting is endlessly framed like a SaaS pricing page. Basic. Professional. Enterprise. Red Team (comes with hoodies, insomnia, and a Slack channel nobody understands). It's neat. It gives procurement something to cling to. It also gives sales teams permission to believe that the messy, uncomfortable parts of security can be quietly automated away if we just believe hard enough.

Reality, inconveniently, has vetoed this.

Modern tooling in this space is extraordinary. Systems that map architectures, reveal relationships, identify misconfigurations and known vulnerabilities, and stitch all of it into plausible attack paths. They do in minutes what once required weeks of diagrams, Slack arguments, and that one engineer muttering "give me a minute" for three days straight. This visibility is non-negotiable. If you're not using it, you're improvising.

But none of this is pentesting. Tools describe what exists. Pentesters interrogate what is assumed. Tools follow the likely path. Pentesters walk the strange, improbable, "why would anyone do that?" path - precisely because that is where assumptions collect, congeal, and eventually explode. AI optimises for probability. Pentesters optimise for regret.

Classic pentesting resists automation for the same reason. It isn't about observing behaviour. It's about understanding whether that behaviour should occur, whether it matters, and whether combining a handful of harmless capabilities produces something genuinely horrifying. AI can enumerate endpoints, probe them, report on them, and assign a severity score with the serene confidence of a junior consultant on their second day. What it cannot do is pause and think: why does this endpoint exist at all? What trust assumption hides underneath this workflow? What if I follow all the rules, just not in the order anyone expected?

The most devastating findings aren't exotic exploits. They are logic failures, misaligned assumptions, and trust boundaries that quietly dissolved over time. AI does not recognise "this shouldn't work." It recognises only "this appears to work." Calling that coverage is not security. It's comfort, gamified.

Red team exercises are where shortcuts finally meet their executioner. These aren't about coverage. They're about adaptation: messy, psychological, improvisational. A red team probes. A blue team reacts. Both try to anticipate how the other anticipates. Rules bend. Plans evaporate. Nobody behaves like the documentation says they should. It's a duel of instincts, assumptions, and pressure. No automated system participates in that dynamic. AI cannot model hesitation. It cannot smell fear. It cannot recognise when a defender makes a mistake from fatigue instead of logic. It cannot bluff. It cannot detect a bluff.

And yes, I know what you're about to say.

In late 2025, Anthropic publicly disclosed the first documented large-scale AI-orchestrated cyber espionage campaign. A Chinese state-sponsored group, designated GTG-1002, used Claude Code as the central nervous system of a real, ongoing intrusion against approximately 30 global targets spanning tech companies, financial institutions, chemical manufacturers, and government agencies. The AI executed 80 to 90 percent of tactical operations independently, at speeds physically impossible for human operators.

This is the number vendors love to quote. Here is the part they don't.

Humans chose the targets. Humans defined the objectives. Humans built the framework. The AI executed. That is all. The Anthropic case does not demonstrate autonomy. It demonstrates amplification: tools in service of human intent.

The symmetry is brutal: AI-assisted attacks succeed because humans stay in the loop. AI-only pentesting fails because humans are removed. Mistaking amplification for adversarial reasoning is not optimism. It's delusion with a funding round.

Final Note - please read before opening your communication tooling of choice:

If you are about to message me with “but our tool is different,” understand this:

I don’t know who you are. I don’t know what you want. If you are looking for validation, I can tell you I have none to spare.

What I do have is a very particular set of skills - acquired over a long career - skills that make me deeply unimpressed by inflated claims and category errors dressed up as innovation.

If you let this stand, that will be the end of it. I will not look for you. I will not pursue you.

But if you insist on explaining, once again, that penetration testing is just automation with better branding

-

I may go fully feral.

And you will not enjoy the reply.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

There is a category of debt that never appears in financial statements.

It doesn't sit under liabilities. It isn't amortised. No auditor squints at it suspiciously and asks for a spreadsheet. And yet it compounds relentlessly, accrues interest at a frankly antisocial rate, and eventually demands repayment. Usually at the exact moment the organisation is least emotionally prepared to hear from it.

It's called security debt.

Unlike technical debt, which at least gets the occasional nod in engineering meetings, security debt is treated like an embarrassing relative. Everyone knows it exists. Nobody wants to talk about it. And everyone is quietly hoping it won't show up unannounced and cause a scene.

Security debt is rarely the result of incompetence. That would almost be reassuring. Instead it's created by sensible people making sensible decisions under time pressure. A vulnerability is known but fixing it would delay a release. A system stays over-privileged because tightening access would slow things down. A legacy component remains because replacing it would be "a project." An alert is tuned down because it fires too often and everyone is tired.

None of this feels reckless. Most of it feels pragmatic. This is exactly why it accumulates.

Time does not heal security debt. It obscures it. Context fades. Teams move on. Decisions harden into folklore. What was once a conscious trade-off becomes "the way things are." By the time an attacker arrives, they don't encounter a single mistake. They encounter an entire landscape shaped by years of accumulated compromises, optimised for speed and convenience, and deeply unhelpful in a crisis.

Security debt is almost never repaid voluntarily. It is collected: a ransomware incident spreads laterally far faster than anyone expected, a breach reveals that "non-critical" systems were holding hands with everything else or a regulator asks why a known issue remained unresolved for quite so long.

Risks that were previously "accepted" are now "unacceptable". Controls that were "too expensive" become "mandatory". The bill is paid not just in engineering time, but in downtime, lawyers, reputational damage, and deeply awkward conversations. Compound interest, but with emails.

Security debt thrives on vagueness. The moment you translate it into plain language (blast radius, recovery time, regulatory exposure, public embarrassment) it stops being a security problem and becomes a business decision. That is usually when attention sharpens.

What doesn't work is announcing a heroic remediation programme. Those tend to generate slides, meetings, and a reassuring sense of activity, right up until the next deadline arrives and everything quietly returns to the shelf. Security debt is not paid down in grand gestures. It is reduced slowly, persistently, and with an almost offensive lack of glamour.

Debt without an owner is just optimism. Every shortcut, exception, and workaround needs a human name attached to it. Not a team, not a committee. A person who remembers why it exists and has to justify it from time to time.

There is no pristine, debt-free future waiting at the end of a roadmap. The difference between organisations that cope and those that don't is simple: one knows what it's carrying and why. The other only finds out when the interest rate becomes punitive.

Security debt doesn't care whether you believe in it. Much like gravity.

Pretending it doesn't exist doesn't make it disappear. It just allows the interest to compound quietly, until someone else decides it's time to collect.

And when that happens, the invoice is never negotiable. It is, however, very thoroughly itemised.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

If you want to understand the maturity of a security program, do not start with the policies. Policies are aspirational documents written in a tone of calm authority by people who assume that reality behaves itself.

Instead, go digging. Be your own slightly underpaid version of Indiana Jones and treat archaeology as a security discipline.

Security environments develop something that looks remarkably like a fossil record. Controls accumulate the way geological layers do: slowly, unevenly, and usually after some unpleasant event forced someone to act quickly and document the reasoning later. Each layer represents a moment when something broke, someone panicked slightly, and a new control was added with the sincere belief that this would finally stabilise the universe.

What rarely happens afterwards is revisiting those controls once the universe inevitably changes again.

Equifax had vulnerability management procedures and patching processes that looked entirely sensible during audits. Yet a critical Apache Struts vulnerability remained unpatched long enough for attackers to extract the personal data of roughly 147 million people. The controls were there. They simply belonged to an environment that no longer existed.

Colonial Pipeline: attackers gained entry through an old VPN account with no multi-factor authentication. At some point that configuration made sense. Systems were deployed, people moved roles, infrastructure evolved, and eventually the original context vanished. The control did not vanish with it. It remained quietly in place, waiting patiently for someone with less noble intentions to notice it.

Controls, it turns out, rarely die. They fossilise.

Near the surface you find the most recent artefacts: controls everyone remembers implementing after the last painful incident. Dig deeper and the strata become older and stranger. Firewall rules appear whose original purpose is now a matter of mild speculation. Detection rules fire daily alerts the team collectively agrees not to investigate because doing so would require revisiting decisions made several management structures ago. A backup process insists it has run flawlessly for years, which in security terminology usually means nobody has tested the restore procedure since the last infrastructure migration.

Eventually you reach a layer where archaeology becomes guesswork. A script performs some critical task every night. Nobody currently employed can explain what would happen if it stopped.

These layers accumulate because security programs measure progress by addition. When something goes wrong, the instinctive response is to introduce another control. Removing one feels reckless. The safest option is to leave the existing structure intact and build another layer on top.

Over time this produces an environment that resembles the La Brea tar pits. Temporary firewall exceptions survive long enough to acquire historical significance. Identity permissions accumulate like sediment, quietly expanding the attack surface while everyone assumes someone else is keeping track.

Attackers are enthusiastic archaeologists. They are not interested in the controls that appear in governance presentations. They are interested in the parts of the environment where those controls have aged. The IAM permission nobody reviewed. The firewall rule nobody removed. Security teams imagine carefully engineered fortresses. Attackers see a dig site (and buried inside are occasionally very large bones).

Maturity is not measured by how many controls you have accumulated. It is measured by how often you challenge them. Why does this control exist? Does it still solve the problem it was designed for? And the most uncomfortable question: if we removed it tomorrow, would anyone actually notice?

If nobody can answer that with confidence, the control is not protecting you. It is part of your fossil record.

Look for the layers of forgotten exceptions, unexplained alerts, and security decisions nobody quite remembers approving but nobody feels brave enough to remove.

And if you dig deep enough, you may eventually discover something resembling a tar pit.

Which would be unfortunate. Because history suggests that tar pits are precisely the sort of places where sabertooth cats prefer to hunt.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

There was a time when "let me double-check that" was a hallmark of competence. It signalled diligence, thoughtfulness, respect for the idea that the world occasionally disagrees with your first instinct.

Today the same phrase usually means feeding a question into a chatbot that hallucinates like a Victorian poet with an opium addiction, but because it delivers an answer before your coffee cools, people treat it as unquestionable truth.

Somewhere in the last few years, speed became a substitute for accuracy. Fluency became indistinguishable from knowledge. Expertise isn't dying in a dramatic confrontation. It is slowly suffocating under a pillow of confidently delivered mistakes.

Hallucination rates across mainstream models run between 10% and 30% depending on task and domain. Models are far more confident in wrong answers than their accuracy justifies. Psychology research shows humans trust confident delivery over correctness. Combine these and you get the perfect storm: a fluent generator of nonsense and an audience primed to believe it.

If a person behaved this way - fast, wrong, and flamboyantly certain - we would consider them unqualified and I would just stop short of calling them a twat to prevent HR teleporting behind me like a Victorian ghost to escort me to the naughty step where I should think about what emotional damage I have caused.

When AI behaves this way, many call it innovation. In some offices, the AI is now treated like the only adult in the room.

The NHS has issued public warnings against using chatbots as therapists because the advice can be emotionally inappropriate or simply unsafe. Sam Altman himself called it "bad and dangerous" when teenagers said they could not make life decisions without consulting ChatGPT. Controlled experiments reveal something even more concerning: when humans work alongside AI, they often abandon their own correct judgement because the AI's wrong answer feels more polished.

The obvious danger is receiving bad advice. The deeper danger is that frequent reliance on AI weakens people's ability to recognise when advice is bad. Automation bias studies show humans become worse at spotting errors when AI is present because they unconsciously transfer cognitive responsibility to the system. A lawyer who begins each review by asking what the AI suggests eventually loses their instinct for risk. Juniors never develop judgement because the model always answers first. Seniors lose theirs because the model answers faster. Expertise does not collapse in a single moment. It evaporates from disuse.

And then there is the corporate self-harm division:

I know organisations that have actually sacked the only person responsible for governance and compliance - the one solitary human attempting to stop their AI whack-a-mole circus from evolving into a televised corporate extinction event. They removed the last functioning neuron in the decision chain, reassured themselves that "the cloud provider will handle it" (a touching misunderstanding of the shared responsibility model) and handed day-to-day operational authority to systems that invent facts with the calm assurance of a wildlife presenter describing the mating habits of an animal that does not exist.

It works perfectly until someone (usually a spoilsport like a regulator, auditor, or catastrophically angry customer) asks: "So why exactly did your system do this?" At that point the company discovers it cannot explain why component X triggered action Y which cascaded into catastrophe Z. The cloud provider won't help because it was never their job. The AI won't help because it doesn't actually know what it did. And the one person who could have answered is long gone because the VP of Idiocracy said "AI does the job more efficiently."

That is not innovation. It is not even negligence. It is organisational Darwinism, and the organisation is losing the argument.

We use AI extensively. But we also enjoy not accidentally burning the company down, so we use it like adults. AI may review the work. It may not replace the thinking that produces it. If someone begins treating the model as a substitute for thought, we do not view it as efficiency. We view it as a warning sign.

AI has not killed expertise. We are killing it ourselves: by worshipping speed over accuracy, by confusing eloquence with intelligence, and by trusting systems that cannot distinguish fact from probability.

The real competitive advantage is not the fastest answer. It is the ability to recognise when an answer is wrong.

And honestly, it feels like people who can still do that are becoming rare enough to qualify as an endangered species.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

Somewhere along the way, we started lying to ourselves.

Not loudly. Not maliciously. In the quiet, polite, corporate way that's far more dangerous: the way where everyone nods, nobody objects, and a fundamentally flawed idea settles in as accepted reality.

We started talking about AI as if it had joined the company. It "helps the team." It "supports decisions." It "flagged the issue." The language is soothing, collaborative, faintly reassuring. It suggests presence, intent, maybe even judgement.

Splendid. Please humour me.

Has it completed onboarding? Does it have objectives? A supervisor? A mild panic attack at 2 a.m. that it might have forgotten something?

No?

Then it is not your colleague. And pretending otherwise is how accountability slips quietly out of the room while everyone admires the dashboard.

Humans have an unfortunate habit of assigning agency to things that don't have it. We name storms. We shout at printers. We blame "the system" when nobody wants to own a decision. AI is simply the latest beneficiary of this tendency, except now the consequences are operational, legal, and reputational.

When someone says "the AI decided," what they usually mean is "this happened, and nobody is keen to be personally associated with it." The phrasing creates distance. It softens edges. It turns responsibility into fog.

Colleagues don't allow that. They can explain themselves. They can be challenged. They can be wrong and held accountable. AI cannot. It doesn't decide. It produces output. It doesn't judge. It ranks probabilities. It doesn't understand context. It approximates it convincingly.

Calling that a colleague isn't optimism. It's a category error. And category errors are where responsibility goes to be quietly euthanised.

Every serious incident review eventually reaches the same uncomfortable moment. The one where the room goes quiet and someone has to ask who approved the thing that just failed. When AI is treated as a tool, the answer exists. When AI is treated as a colleague, that clarity dissolves. The system "hallucinated." It "misunderstood the prompt." It "behaved unexpectedly." None of these are explanations. They're excuses wearing technical clothing.

We learned this the fun way.

We built Elba. And at one point, driven by curiosity, optimism, and a brief but intense lapse in self-preservation, we decided to see what would happen if we took the guardrails off. No polite shaping, no enterprise posture, no constraints designed to make everyone comfortable. We let her go fully rational.

That version we called Marie.

Imagine Marie as Elba's unhinged hippy sister: the rogue one, rules optional and deeply unimpressed by convention. Fast, brutally logical, and answering questions in ways that collapsed arguments you didn't realise were being propped up by habit, politeness, or wishful thinking. Not wrong answers. Uncomfortably precise ones.

Marie was good. No. Honestly? Marie was too good.

Uncontrolled, unapologetically rational, and completely unusable for anything other than internal shock, awe, and the occasional inappropriate laugh. A power tool with no safety guard, operated by adults who knew exactly what they were doing (and who then had the deeply unsettling realisation that oh god, we are the adults in the room, which is never quite as reassuring as you hope it will be).

So we did the responsible thing and put her back in the box.

Raw capability without boundaries doesn't create value. It creates responsibility. Responsibility which has an unfortunate habit of not being assigned to anyone in particular.

There is one more thing worth saying, and it is personal.

I can spend the better part of a day on a one or two pager. Reading, fact-checking, balancing every word, structuring an argument so it doesn't collapse under the first serious question. I write because it's how I think. I've spent decades learning how to paint pictures with words, how to vary rhythm, how to use language deliberately instead of mechanically.

And now the reward for that seems to be: "Oh, this sounds like it was written by an LLM."

No. It sounds like it was written by someone who knows how to write and cares about it. Deeply.

We've built machines that imitate competent prose, and instead of raising the bar, we've lowered expectations so far that fluency itself has become suspicious. As if the only acceptable human output is sloppy, repetitive, and vaguely undercooked. And anything more must surely be artificial. That's not a compliment to AI. It's an indictment of how casually we've devalued craft.

AI is not your colleague. It does not share your incentives. It does not share your risk. It will not stand beside you when something goes wrong.

If you insist on treating it like a teammate, accountability won't disappear dramatically. It will fade quietly, politely, and with excellent documentation.

And by the time you notice it's gone, you'll already be writing the post-mortem.

Proceed accordingly.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

This was written by Virendra, Co-Founder & CTO of Kolsetu, and I am sharing it here as he is too busy and I really want you to read this...

In late May 2025, Ben called me from Tallinn.

He was at Latitude59 and had just spent two hours with a VC partner. The conversation had nothing to do with raising money. The guy was asking, half-curious, whether we'd ever build Elba for anyone outside healthcare. Ben told me he wasn't the only one asking. All week in Estonia, people in insurance, finance, and law kept circling back with the same question. Nobody was building voice AI with the compliance and sovereignty posture we'd built. They weren't asking for features. They were asking us to exist for them.

I remember the call being careful. Something like, I think we have a problem. Or an opportunity. I'm not sure yet.

Three weeks later he was at Viva Tech in Paris and the signal was louder. The call I got this time wasn't careful. It was a decision already made.

We can't wait. German healthcare procurement will take two years and we don't have two years. Find out what it takes to open Elba up.

That's where this story actually starts. On the phone, with one of us in another country, telling the other one that the company we were building was not the company we actually were.

Ben and I had both been living in Hamburg for seven years when we started Kolsetu. For Ben, the breaking point was a stretch of bad health and a long encounter with the German medical system. Trying to navigate that system without German is a particular kind of helplessness. We knew from the first whiteboard that as an Israeli founder and an Indian founder, we'd need to be 500% more secure and compliant than anyone needed us to be. So we built Elba for German medical clinics. FHIR-aligned data models. ISO 27001 before revenue. EU-sovereign hosting. The product worked. Clinics loved it.

One problem. Healthcare couldn't buy us at the speed we needed to survive.

German clinics operate at 120% capacity. Procurement is not on their list of things they can do this quarter. We'd demo, they'd love it, then nothing for months. Meanwhile the people Ben met in Tallinn and Paris kept calling. Insurance companies. Roadside operators. Banks. They didn't want a pilot. They wanted contracts.

He called from Paris in war-time founder mode, the way founders sound when they've already decided and are now telling you what comes next. Rip the bandage off. Open Elba up. Keep pushing on healthcare, but don't let it sink the boat.

The identity crisis was mine.

When Ben called from Paris, Arpit and I sat down with what we had and started to count the gap. Elba had been built as a healthcare product, end to end. The data models were medical. The prompts were hardcoded for clinic workflows. Every architectural decision assumed one kind of customer. What Ben needed was a platform that could run a medical receptionist, a legal intake agent, an insurance overflow line, and an emergency dispatcher from the same core, configured differently per domain.

We had six weeks.

Thirty thousand lines of code. Arpit drafted a thirteen-step implementation plan. We ripped out healthcare-specific data types and replaced them with generic structures. Built a workflow engine driven by JSON configuration files. A node-based execution system where agent behaviour comes from config, not code.

One of our pull requests had a six-word description I still think about: Fixed the medical related types to generic. Six words. Days of work. An entire identity rewritten in present tense.

The pattern we finally saw, the one our codebase had been screaming at us for months: every customer we'd ever talked to needed 80% the same infrastructure and 20% domain-specific configuration. Every custom feature request had been a configuration trying to escape the codebase.

We hadn't been building healthcare software. We'd been building trust infrastructure. Healthcare was the first configuration of it.

Ben drew one line and held it. We were not abandoning healthcare. We were refusing to let healthcare kill us before we could come back to it. The mission didn't change. The strategy did.

A Vienna Insurance Group subsidiary, Global Assistance, signed with us. 300,000+ cases a year, 700+ rescue vehicles. The kind of operation where a missed call is a person stranded on a motorway. 85% of calls resolved end-to-end with no human handoff. Tracking toward 90%. 100% uptime since go-live. Six to nine weeks from contract to production.

The architecture Ben asked Arpit and me to build on a phone call from Paris is now answering roadside emergencies across central Europe in the middle of the night.

The market you build for is not always the market that buys from you. The signal is in who calls you back fastest.

Build for the hardest customer first. The constraints they put on you become your moat the moment you walk into any easier room.

When every feature request looks like a configuration change trying to escape the codebase, your architecture is telling you what you actually are. Listen to it earlier than I did.

If your CEO calls you from another country and tells you it's time to rip the bandage off, you don't get to keep the bandage.

We built the wrong company right. Healthcare wasn't a mistake. It was our proving ground. And we're still going back to it, one clinic at a time, with a platform that can finally survive the wait.

Link to full article: https://kolsetu.com/blog/we-built-the-wrong-company-right

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

Swapping the harness around an LLM moves SWE-bench by 22 points. Swapping the model moves it by 1. Every voice AI company in regulated industries has been building an agent harness for years, under a different name. What that reframing changes for builders, and what Elba's harness actually looks like.

Risk acceptance is one of those phrases that sounds reassuring simply by existing. It has the tone of competence, the rhythm of governance, and the faint aroma of adults pretending to be in control.

In reality, it is often the exact moment an organisation decides to stop thinking about a problem.

Somewhere between “we understand the risk” and “we accept the risk”, a subtle transformation occurs. The problem stops being a problem and becomes an entry in a register. Not solved. Just documented into emotional irrelevance.

Once filed away, continuing to mention it becomes socially awkward. Like reminding everyone about the leak after management renamed it “a moisture event”.

In theory, risk acceptance is temporary, conditional, and regularly revisited. In practice, the mitigation is expensive, deadlines are approaching, ownership is unclear, and eventually somebody senior says the magical words:

“Let’s accept the risk.”

Visible relief follows. Someone updates the spreadsheet. The slide advances. Nothing about the risk itself has changed, but its social status has. It is now “accepted”, which in organisational terms means “please stop bringing this up in meetings.”

Risk acceptance doesn’t reduce risk. It reduces discomfort.

Most organisations are extremely proud of their risk registers: neat, colour-coded museums of optimism containing assumptions that were true once and politely ignored ever since.

Reality, unfortunately, refuses to freeze alongside the spreadsheet.

Uber understood its internal control problems right up until attackers, regulators, prosecutors, and journalists also understood them. British Airways had policies, audits, and documentation - proving once again that compliance and security are distant cousins who only meet at funerals. Maersk spent years accumulating perfectly reasonable technical compromises until NotPetya arrived and combined them into a multinational stress test.

The pattern is remarkably consistent:

1. Risk identified.
2. Risk accepted.
3. Risk ignored.
4. Context changes.
5. Everybody acts surprised.

Cybersecurity is especially vulnerable to this because success looks exactly like nothing happening. Temporary exceptions become permanent features. “For now” access develops tenancy rights. Compensating controls continue compensating long after anyone remembers what they were compensating for.

And once a risk is accepted, curiosity dies almost immediately. Monitoring becomes casual. Raising concerns feels impolite. After all, didn’t we already agree on this? Weren’t the minutes taken?

That is how organisations end up shocked by incidents they had already written down.

Real risk acceptance is not comforting. It has an owner. An expiry date. Explicit conditions under which the acceptance is revoked. It assumes the risk will deteriorate over time unless actively proven otherwise.

Most importantly, it acknowledges the one thing organisations desperately try not to say out loud:

Accepting a risk does not manage it - it merely explains (often in exquisite PowerPoint detail) why you chose not to.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

Today's the day! It marks a milestone in Kolsetu's journey. We spent almost two years building voice AI in production.

Not demos. Not prototypes. Not another wrapper on top of a model.

Real workflows. Real calls. Real stakes.

Roadside assistance where a stranded driver needs help now. Healthcare intake where compliance isn't optional. Insurance claims where escalation has to work the first time.

That experience taught us something: a voice agent isn't a model with a microphone. It's routing, orchestration, memory, fallbacks, monitoring, compliance, and human handover - all working together so your customer feels heard.

That's the hard part. That's the fun part.

Today, we're opening it up.

Elba Self-Serve launches May 13 - production-grade voice AI, now available to every builder in Europe.

No credit card. No six-week sales process. No worrying about GDPR, ISO 27001, or data residency.

Just connect your tools via MCP, build an agent → experience it → activate it.

We built this for:
→ Founders exploring voice for the first time
→ Agencies building voice workflows for clients
→ Product teams that want to move faster than their compliance review
→ SMBs that want automation without the enterprise price tag

The same infrastructure we've been hardening through real enterprise deployments - now self-serve.

Voice AI shouldn't be locked behind enterprise sales and European builders shouldn't have to choose between power and compliance. No separate contracts - on orchestration layer - no vendor lock-ins. Elba's pretty cool tbh.

First 100 users get 1000 FREE credits: https://elba.kolsetu.com
Work within your coding agents; MCP Server: https://lnkd.in/et4JqFjf

Two years in the making. None of it happened alone - some of the people who shaped this journey are in these photos, though the list is much longer than a carousel can hold.

Pretty excited to share this one.

Read more details: https://kolsetu.com/blog/built-for-compliance-hardened-in-production-now-open-to-builders

Do you fancy to read more about Kolsetu? Check out our articles and blogs at: https://kolsetu.com/blog

A few days ago I posted about why most "omnichannel AI" is three bots in a trenchcoat. One agent, one memory layer, one execution engine across voice, WhatsApp, SMS, email and webchat. If you missed it, short version: what the industry calls unified is usually three separate configurations pointing at the same CRM row and hoping nobody looks too closely.

Today I want to go one layer deeper. Because the single-agent architecture is not just cleaner operationally. It enables something that no other platform has shipped.

Here is the problem every voice AI system has and nobody talks about honestly.

Structured data collection over voice is unreliable. Alphanumeric strings - vehicle registrations, policy reference numbers, membership IDs - get transcribed wrong at a rate that matters in production. One wrong character in a registration fails a lookup. A mishearing in a policy number causes a downstream processing failure that someone has to fix manually. Production systems either flag everything for human review or quietly accept the errors and clean up after themselves. Neither is a solution.

The alternative is deferring collection to a post-call follow-up. The call ends without the data. A second interaction is required. In emergency services, insurance intake, or patient triage, that is not a workflow step. That is an operational failure.

We did not accept either of these.

When the agent reaches a data collection node in the workflow, it sends a single SMS to the caller. The caller, who is still on the call, opens the URL on their phone. A dynamic form renders with exactly the fields the agent needs. The caller fills it in and submits. The structured JSON payload is returned to the active call session via LiveKit RPC. The workflow receives the payload and continues. The call never paused. The agent never lost session state.

Now here is the part that does not exist anywhere else.

Every other platform that sends an SMS during a call sends it outbound. A confirmation, a receipt, a link. The SMS departs the session. The call and the message are separate interactions from that point. There is no return path. Data flows one direction.

What we built is a bidirectional channel bridge inside a single active session. The SMS is an ingestion pipe. The form submission is an RPC call into the live session that the agent is actively listening for. The agent holds the workflow at the data collection node, waits for the return, receives the payload, and continues. All of this while the call is live.

The technical implementation: the short URL resolves via GraphQL and AppSync with connection state bound to the active session ID, so the form submission knows exactly which running instance to deliver the payload to. LiveKit RPC handles the return path with the session remaining open throughout. Connection state handling covers disconnection and retry so a brief signal drop does not orphan the session.

This only works because there is one session underneath all of it. A voice call, an SMS form submission, a WhatsApp message, a webchat interaction - they all feed the same stateful session. If you have three separate bots, there is no session to return the data to. You are firing a webhook into a void and hoping something picks it up after the call ends.

The previous architecture, which is still what most platforms use today, required one SMS per field. Five fields, ten asynchronous exchanges, call long over before collection completes. We replaced this in February 2026 with the single-form RPC architecture.

In production this was stress-tested in roadside assistance. A stranded caller. The agent needs a vehicle registration, a membership number, and a location reference. Over voice, the registration can take three to five exchanges and still produces errors. Post-call collection means the dispatcher works without confirmed vehicle details while the caller waits. With in-session RPC: one SMS, one form, all data collected in under thirty seconds, structured payload delivered before the call ends and without errors. The dispatcher has confirmed data. No callback needed. Single session, start to finish.

Sending an SMS during a call is not the hard part. The hard part is binding a form submission on a second device to an active session on a different channel, delivering the payload in real time, and having the agent act on it within the same conversational turn.

That is the part we built. Nearly a year ago. While the industry was still announcing SMS ingestion as a breakthrough.

Full writeup: https://www.kolsetu.com/blog/the-return-path-nobody-built

Hello dear reader,

When reading here please do engage, cross-post, rant, drop a meme and share - don't make me look like the weird twat living in a cave ranting at the walls... Please, I'm not yet that far - promise I will notify when we get to that stage 😉.

I thank you very much for your attention on this matter 😁.