{"posts":[{"id":6,"founder_id":"alexandre","post_urn":"urn:li:share:7505960818153328640","document_urn":null,"linkedin_url":null,"text":"In January 2013, the Basel Committee on Banking Supervision published 14 principles for effective risk data aggregation and risk reporting. They applied to the world's largest banks. The deadline for full compliance was January 2016.\n\nThe principles themselves aren't particularly exotic. Banks should be able to trace their risk data from source to board report. The data should be accurate and complete, available when needed, and subject to clear ownership and governance.\n\nMore than a decade later, the interesting question isn't really whether those principles were sensible. It is what happens when you examine the organisations that were actually able to make them work.\n\nBecause if you receive a report telling you that two of the thirty-one assessed have apparently managed to build capabilities that the others have not, the obvious question is:\n\nWhy those two?\n\nWhat were they able to do that the others weren't?\n\nAnd that question is rather different from asking what technology they bought, what processes they documented, or what governance framework they adopted.\n\nIt asks what organisational characteristics allowed those capabilities to emerge — and, perhaps more importantly, to survive.\n\nThere is another complication. A mature capability isn't necessarily the thing that was originally designed and documented.\n\nOrganisations evolve. Systems are replaced. Processes get adapted. People solve problems that the original architects never anticipated. Controls are added, bypassed, repurposed or absorbed into other processes.\n\nEventually, what actually works may be quite different from what the documentation says was built.\n\nThat creates an uncomfortable diligence question.\n\nWhen an organisation demonstrates an apparently sophisticated capability, are we looking at something deliberately designed and institutionally maintained — or something that emerged over time through accumulated adaptation, without anyone necessarily maintaining a coherent record of how it got there?\n\nAnd if it works, does that distinction matter?\n\nI think it does.\n\nBecause the real test of organisational capability isn't simply whether a capability exists today. It is whether the organisation understands why it exists, who owns it, what makes it work, and whether it can reproduce or adapt it when circumstances change.\n\nThat is where the Basel principles become interesting.\n\nNot as a checklist.\n\nAs a test of whether an organisation can actually know itself.","title":null,"post_type":"text","pdf_filename":null,"pdf_pages":null,"posted_at":"2026-09-16T12:08:33.811604+00:00","scheduled_at":null,"status":"published","error":null,"created_at":"2026-09-16 12:08:33","platform":"linkedin"},{"id":5,"founder_id":"alexandre","post_urn":"urn:li:share:7503301604461166592","document_urn":null,"linkedin_url":null,"text":"Code is ugly by default.\n\nYou write a program, you run it, and if something is wrong it tells you. It crashes. It throws an exception. It returns an error that points you to the line where things went sideways. The default state of code is: something breaks, you see it break.\n\nProgrammers spend enormous effort making code graceful. Left to its own devices, code fails loudly and stops.\n\nAI has almost the opposite problem.\n\nAI is pretty by default. You give it a prompt, it gives you a response. Always. It doesn't normally fail in a way that announces itself. It gives you an answer. It fills gaps. It resolves ambiguity on its own. It works around problems you did not know existed in your instructions. And it sounds confident either way, whether it followed your intent or wandered off in a direction you never asked for.\n\nIn code, success and failure look different. A crash looks nothing like a working program. You do not need domain expertise to tell them apart.\n\nIn AI, they look identical.\n\nA response that followed every instruction and one that quietly ignored half of them can look exactly the same. You cannot tell them apart without doing the verification work yourself.\n\nThat is manageable when AI produces a paragraph at a time. It is not manageable when it produces forty pages. So you skim. You check the first few pages carefully and pattern-match the rest. You catch formatting problems and obvious errors. You miss the number that is plausible but wrong. The claim that sounds authoritative but contradicts something from three sections earlier.\n\nAI increases production. It does not increase review capacity.\n\nYou can make AI fail loudly. You can write instructions that tell it to flag uncertainty, to refuse when it cannot verify, to show its reasoning. But these are still instructions. And the mechanism that enforces them is the same mechanism that might ignore them. You are relying on the system to police itself, using the same interpretive process that caused the problem.\n\nThe industry response so far has been to build better ways to organise instructions. Projects. Skills. Memory. Modules. Persistent rules that carry across conversations. These are genuinely useful. They bring structure to the chaos of a single growing prompt document.\n\nBut the quality mechanism has not changed. It is still: a human reads the output and decides whether it looks right.\n\nAnd I think that's the gap we're still largely ignoring. If AI can produce forty pages in the time it used to take us to produce four, the bottleneck hasn't disappeared. We've just moved it. Someone still has to establish that those forty pages are actually right.\n\nWe have solved the production problem much faster than we've solved the verification problem.","title":null,"post_type":"text","pdf_filename":null,"pdf_pages":null,"posted_at":"2026-09-09T04:01:47.885776+00:00","scheduled_at":null,"status":"published","error":null,"created_at":"2026-09-09 04:01:47","platform":"linkedin"},{"id":4,"founder_id":"alexandre","post_urn":"urn:li:share:7501102550566227968","document_urn":null,"linkedin_url":null,"text":"One of the first things I did as Data Protection Officer was read every data processing agreement we had signed.\n\nThere were not many. We are a small company, and we are careful about which processors we engage. But every DPA we had was one that a vendor had provided to us as their standard agreement. The assumption, on both sides, was that a standard DPA from an established provider would cover what the GDPR requires.\n\nSo I checked. We use an eight-point assessment that maps directly to the obligations in Article 28: processor and controller identification, processing scope and purpose, sub-processor controls, data subject rights, breach notification, security measures, audit rights, and data return or deletion at the end of the engagement. Each point corresponds to something the GDPR says the agreement shall contain.\n\nOne of our DPAs failed on three of the eight points. Breach notification timelines were vague. Sub-processor obligations had no notification or objection mechanism. The data subject rights clause was written for data subjects, not for controllers. We contacted the vendor with specific references to the gaps. They have not responded.\n\nThis is a company we otherwise have no complaints about. The service works well. The relationship is professional. The DPA is simply incomplete, and the vendor either does not know or does not consider it a priority.\n\nOur experience turns out to be unremarkable. A research team at the University of Luxembourg built an NLP-based system that checks data processing agreements against 45 compliance requirements extracted from GDPR, developed in collaboration with legal experts at Linklaters. They tested it against 30 real DPAs from organisations in banking, healthcare, telecommunications, and cloud services.\n\nAcross those 30 agreements, the system identified 750 genuine violations. That is an average of 25 requirement gaps per agreement, out of 45 total requirements. More than half of what GDPR requires was missing from a typical DPA.\n\nThe gaps were not random. They clustered around breach notification to supervisory authorities, sub-processor liability provisions, and international transfer safeguards. The same areas where our own assessment found problems.\n\nWhat makes this worth thinking about is not that DPAs have gaps. It is what DPAs are for. Under GDPR, the data processing agreement is the mechanism through which compliance transfers from a controller to a processor. It is the document that makes a controller accountable for what a processor does with personal data. If the agreement does not cover what the regulation requires, the chain of accountability has a gap in it. Not a visible gap. There is a signed document on file. The checkbox is checked. From the outside, it looks exactly the same as a DPA that actually covers everything.\n\nThe compliance framework designed to ensure that data protection obligations are implemented in practice has the same weakness as any other system: the description of what it should do and the reality of what it does can quietly drift apart, and nothing in the process flags the difference.","title":null,"post_type":"text","pdf_filename":null,"pdf_pages":null,"posted_at":"2026-09-03T02:23:32.560228+00:00","scheduled_at":null,"status":"published","error":null,"created_at":"2026-09-03 02:23:32","platform":"linkedin"},{"id":3,"founder_id":"alexandre","post_urn":"urn:li:share:7498313259721289728","document_urn":null,"linkedin_url":null,"text":"There is an old saying: the cobbler's children have no shoes.\n\nA bank I worked at had a system that existed for one purpose: to establish a single, authoritative record of who every customer was. It pulled data from multiple sources, reconciled identities, and produced the golden record that the rest of the organisation depended on for reporting and compliance.\n\nThe system worked. But the system itself had no documentation. No lineage. No explanation of how it arrived at its own answers.\n\nThe thing built to establish provenance had no provenance of its own.\n\nLast month, security researchers found that a cybercrime group had left one of its own servers open on the internet for three weeks. Their tools, their logs, their target lists, all publicly accessible. A group whose entire operation was exploiting other people's security failures was undone by their own.\n\nThere is a version of this in every organisation. The backup that has never been tested for recovery. It runs every night. Nobody has ever checked whether it actually restores. But it runs on schedule, so everyone sleeps well. The version history managed in a file called budget-final-v3-FINAL-updated-use-this-one(2).xlsx. Four people have the latest copy. None of them agree which one it is.\n\nThe pattern is always the same. The closer you work to a problem, the easier it is to assume you have solved it for yourself.\n\nExpertise doesn't protect you from the problem. Sometimes it is the reason you stop checking.\n\nThat is part of why DiligenceWorks exists. Not to replace the people doing the work. To be the outside eye they cannot be for themselves.","title":null,"post_type":"text","pdf_filename":null,"pdf_pages":null,"posted_at":"2026-08-26T09:39:53.494928+00:00","scheduled_at":null,"status":"published","error":null,"created_at":"2026-08-26 09:39:53","platform":"linkedin"},{"id":2,"founder_id":"alexandre","post_urn":"urn:li:share:7495792684318531584","document_urn":null,"linkedin_url":null,"text":"What happens when a technology becomes essential before the rules governing it are ready?\n\nAadhaar offers one answer.\n\nAadhaar (/aːd̪ʱaːr/) is India's national biometric identity system. It gives residents a unique 12-digit identity number linked to demographic information, fingerprints and iris scans.\n\nThe scale was extraordinary. By 2018, around 1.2 billion people had enrolled, making it the world's largest biometric identification system.\n\nThe technology scaled. The infrastructure scaled. Billions of authentication requests were processed.\n\nBut scale exposed consequences that were harder to solve than the technical problem itself.\n\nIn Jharkhand, researchers found that biometric authentication failures and problems linking Aadhaar numbers to records prevented some people from accessing food they were entitled to receive.\n\nFor some manual labourers whose fingerprints were difficult to authenticate, a failed biometric match wasn't just a technical error.\n\nIt could mean missing a ration.\n\nAnd then there was the privacy side.\n\nIn 2018, *The Tribune* reported that a journalist paid ₹500 — about $8 — to an intermediary for login credentials that provided access to Aadhaar records on a massive scale.\n\nThe records reportedly included names, addresses, photographs, phone numbers and email addresses. UIDAI disputed the characterization as a breach and said biometric data had not been compromised.\n\nBut the episode highlighted the underlying governance challenge. Aadhaar was being deployed at enormous scale while the legal and regulatory framework around personal data was still developing.\n\nWhen Aadhaar was being rolled out, India did not yet have a comprehensive data protection law or an independent data protection regulator. The governance framework was playing catch-up with a system that was already becoming deeply embedded in public services.\n\nAnd this isn't unique to Aadhaar. The same pattern shows up whenever organisations build a data system and leave governance for \"phase two.\"\n\nThe technology gets built.\n\nIt proves useful.\n\nPeople start depending on it.\n\nAnd by then, governance is playing catch-up.\n\nOther systems depend on it. Processes have been redesigned around it. Data has accumulated.\n\nGovernance is no longer something you're designing around the technology.\n\nYou're trying to change the rules of something people already rely on.\n\nThe answer isn't to expect governance to get ahead of technology. It won't always.\n\nThe answer is to build governance that can evolve with it.\n\nBecause the problem isn't that governance is sometimes late.\n\n**The problem is pretending that being late means it can safely be deferred.**","title":null,"post_type":"text","pdf_filename":null,"pdf_pages":null,"posted_at":"2026-08-19T10:44:01.264548+00:00","scheduled_at":null,"status":"published","error":null,"created_at":"2026-08-19 10:44:01","platform":"linkedin"},{"id":1,"founder_id":"scot","post_urn":"urn:li:ugcPost:7495090956677840896","document_urn":null,"linkedin_url":null,"text":"\"Let the AI handle it\" is the most expensive sentence in software engineering right now.\n\nA 2026 study tracked 6,000 real-world coding agent sessions. Not benchmarks. Not controlled experiments. Actual developers using AI tools in production workflows.\n\nFully autonomous AI coding, what the industry calls \"vibe coding,\" produced code with 9x the security vulnerability rate compared to human-only coding. It cost 3x more per committed line.\n\nThe pattern held across the data. The more autonomy developers gave the agent, the worse the output. The developers who reviewed every suggestion, edited, rejected, got better results than those who let it run.\n\nThis is not an argument against AI in coding. It is an argument against unsupervised AI in any production workflow. The coding data just happens to be where someone finally measured it.\n\nThe same dynamic applies to any domain where AI generates output that goes to production. Analysis, compliance documentation, investment recommendations, deal review. The organizations getting value from AI tools are the ones that treat AI output the same way they treat any other unverified claim: something to be checked before it ships, not after.\n\nA human in the loop is not a bottleneck. It is the control that separates a tool from a liability.","title":"Vibe Coding: 9x the Vulnerability Rate","post_type":"carousel","pdf_filename":null,"pdf_pages":null,"posted_at":"2026-08-17T12:15:36.968834+00:00","scheduled_at":null,"status":"published","error":null,"created_at":"2026-08-17 12:15:36","platform":"linkedin"}],"count":0}