Software Engineering · Applied AI · Secure Systems · Governance

Insights

A collection of thought-leadership writing on software engineering, applied AI, secure systems, cybersecurity compliance, and engineering leadership — professional judgment and perspective, not a running blog of personal updates.

Latest thinking

Filter by category to find the writing closest to what you're working on right now.

15 insights shown

ISO 27001/27002

From ISO 27002 Controls to Engineering Requirements

An ISO 27002 control catalogue tells a team what outcome is expected — access management, change control, logging — but it rarely says how to build it. Turning control language into something an engineering team can implement means treating each control as a starting question rather than a finished answer. Who owns which resource? What counts as a security-relevant event worth logging? Which changes need a documented approval trail before reaching production? Working through those questions early keeps compliance from becoming a parallel process bolted onto delivery at the end of a sprint. In my experience moving between security governance and hands-on software engineering, the teams that succeed treat controls as inputs to the requirements process, not paperwork to satisfy afterward. This piece walks through a practical way to translate common ISO 27002 control areas into requirements, acceptance criteria, and code review habits that hold up under audit scrutiny.

Applied AI

Building Audit Trails for AI-Powered Applications

AI-powered features complicate audit trails in ways traditional web applications rarely do. It is not enough to log who clicked what; a defensible audit trail for an AI-powered application also needs to capture which model version produced a result, what input shaped it, and what a human reviewer did with that output afterward. Without that context, an incident review or a compliance conversation turns into guesswork about what the system actually did. Designing for this from the start — rather than retrofitting logging once a regulator or customer asks for evidence — means deciding early what constitutes a meaningful event: a generated recommendation, an automated decision, a moment where a human overrode the model. This article walks through a practical framework for identifying what to log in AI-enabled workflows, how to keep that trail tamper-evident and readable months later, and how to balance thorough logging against storage cost and user privacy.

Healthcare Technology

What Hospital Information Systems Taught Me About Reliable Software

Years spent building and maintaining hospital information systems across several operational environments taught me something that generic engineering advice rarely emphasizes: reliability in healthcare software is not a feature, it is the whole point. A hospital system does not get a maintenance window when a shift change happens at 2 a.m., and a slow query is not just a performance annoyance — it can hold up a clinical or administrative task someone is depending on right now. Working across general, military, psychiatric, and maternal-and-child facilities reinforced that different operational contexts still share the same non-negotiables: strict access control, database integrity, and traceability of who touched a record and when. This article reflects on what building for continuous, sensitive, day-to-day operation changes about how you approach uptime, change management, and access design — lessons that apply well beyond healthcare.

Applied AI

Moving an AI Prototype into a Production-Ready Product

A convincing AI prototype and a production-ready AI product are separated by a long list of unglamorous engineering work. The prototype proves the model can produce a good result under ideal conditions; the product has to keep producing an acceptable result under real input, real load, and real cost constraints, day after day. That gap includes input processing and prompt design that hold up outside a demo, an evaluation process for output quality that does not rely on someone eyeballing results, and a latency and cost budget that survives contact with actual usage. Having taken a generative AI capability through this transition for a consumer-facing product, I have found the hardest part is rarely the model itself — it is the surrounding engineering: the pipeline, the fallback behavior when generation fails, and the discipline to keep evaluating quality after launch rather than treating the prototype's early success as a permanent guarantee.

Cybersecurity Compliance

Designing a Cybersecurity Self-Assessment Platform

Self-assessment platforms for cybersecurity compliance sit at an uncomfortable intersection: they need to feel approachable enough for a busy team to use every week, while holding up to the rigor a compliance framework and an eventual audit will demand. Get the balance wrong in one direction and the platform becomes a checklist nobody trusts; get it wrong in the other and it becomes so heavy that teams route around it. From experience contributing to a platform built for exactly this purpose, the recurring engineering challenge is turning compliance requirements into structured, repeatable workflows — assigning clear ownership for each control, keeping supporting evidence organized instead of scattered across email and spreadsheets, and making implementation status visible at a glance rather than buried in a quarterly report. This article walks through the design considerations that make a self-assessment platform genuinely useful rather than a box-ticking exercise.

Applied AI

Why AI Engineers Need Information Security Awareness

It is easy for an AI engineer to treat security as someone else's job — a review that happens after the model works, handled by a separate team. That separation breaks down quickly in practice. The same engineer who chooses how user input reaches a model, how generated output is stored, and how a third-party API key is handled is already making security decisions, whether or not security is in their job title. Without basic information security awareness, those decisions get made by default rather than by intent: input sanitization gets skipped because the demo did not need it, or an API key ends up in a place it should never be. This article makes the case for why AI engineers benefit from the same security fundamentals long expected of backend engineers — least privilege, safe handling of user-submitted data, and awareness of what a secure systems mindset actually changes about day-to-day implementation choices.

Applied AI

Security by Design for Generative AI Applications

Generative AI applications introduce security considerations that a security-by-design checklist written for traditional web applications does not fully cover. Beyond authentication and authorization, a generative AI application has to think about what happens to user-submitted content once it reaches a model, how generated output could be misused, and how much of the surrounding system a user should be able to influence through a prompt. Treating these questions as an afterthought — something to patch once the product is already public — tends to be far more expensive than designing for them from the start. This article outlines a practical approach to security by design for generative AI features: safe handling of user-submitted images or text, clear boundaries around what a model is allowed to affect, and communicating the limits of generated output so users understand what the system can and cannot responsibly do.

ISO 27001/27002

What Developers Can Learn from ISO 27002

Developers who have never worked in a compliance-driven environment often assume ISO 27002 is paperwork for someone else's job. In practice, several of its themes map directly onto habits that make software easier to maintain and safer to operate — regardless of whether an organization is pursuing certification. Thinking about who owns which system component, deciding in advance what a security-relevant event looks like so it can be logged meaningfully, and treating access control as something to design rather than bolt on afterward: these are engineering decisions, not audit decisions, even though ISO 27002 happens to describe them in governance language. This article translates several control themes into concepts a developer can use directly in day-to-day work, without needing to become a compliance specialist or reproduce a standard's control text. The goal is a shared vocabulary between engineering and governance teams, not another document to file away.

Applied AI

Managing User Data in AI Image Applications

AI image applications create a specific data-handling responsibility that is easy to underestimate: every image a user uploads to generate a design or a visual concept is user data, and how it is stored, processed, and eventually discarded deserves the same care as any other sensitive input. In an applied AI product built around image generation, that means being deliberate about how long uploaded images are retained, who or what can access them during processing, and how clearly users are told what happens to their content. It also means being honest with users about the limits of the technology — an AI-generated concept is inspiration, not a professional recommendation, and communicating that boundary is itself a form of responsible data handling. This article looks at the practical decisions behind managing user-submitted images in an AI product: retention, access, and communicating limits clearly, drawn from experience building a home-design product for real users rather than a research demo.

Cybersecurity Compliance

Compliance Is Not the Same as Control Effectiveness

A completed compliance checklist and an effective control are not the same thing, and conflating the two is one of the more expensive mistakes an organization can make. A control can be documented, assigned an owner, and marked complete in an audit tracker while still failing to prevent the incident it was designed to catch — because it was implemented to satisfy the letter of a requirement rather than its intent. Recognizing that gap requires looking past the checklist to ask a harder question: does this control actually change behavior day to day, or does it only exist on paper for the next audit cycle? This article argues for treating compliance as a floor, not a ceiling, and for engineering leaders to build in periodic, honest review of whether controls are working as intended rather than assuming a passed audit settles the question. The distinction matters most in the gap between audits, when nobody is checking.

Software Engineering

How to Design APIs for Traceability and Auditability

An API that works well for its intended users can still be nearly impossible to audit six months later if traceability was never part of its design. Designing for auditability means deciding early what gets logged at each API boundary — not just that a request happened, but who made it, on whose behalf, and what changed as a result — so that reconstructing a sequence of events does not depend on someone's memory of how the system behaves. It also means being deliberate about versioning and about how errors and rejected requests are recorded, since those are often the events an audit actually cares about. Drawing on experience building APIs for platforms operating in regulated and compliance-driven environments, this article walks through concrete patterns for request and response logging, correlation identifiers, and access records that make an API's behavior reconstructable after the fact.

Applied AI

Human Oversight in AI-Enabled Workflows

Human oversight is often treated as a single checkbox — a person approves the AI's output before it goes live — when in practice it needs to be designed as deliberately as the AI feature itself. Effective oversight means being specific about what a human reviewer is actually being asked to judge, giving them enough context to judge it meaningfully, and making it easy to override or reject an AI-generated result without friction. Vague oversight, where a reviewer clicks approve because the interface offers no real way to disagree, provides the appearance of a safeguard without the substance of one. This article looks at what meaningful human oversight looks like in an AI-enabled workflow: clear escalation paths when a model's confidence is low, interfaces that make it easy to understand why a system produced a given output, and honest communication with end users about which decisions were made by a person and which were made, or suggested, by a model.

Engineering Leadership

The Engineering Cost of Ignoring Governance

Governance often gets treated as a constraint on engineering speed, something to negotiate down or defer until later. In practice, ignoring it rarely saves time — it moves the cost downstream, where it shows up as a rushed retrofit under audit pressure, a security incident traced back to a decision nobody owned, or a system so opaque that nobody can explain how it reached a given outcome. Engineering leaders who treat governance as an early design input, rather than paperwork to satisfy at the end, tend to ship systems that are both faster to audit and easier to change later, because ownership and traceability were built in rather than bolted on. This article makes the case, from a hands-on engineering perspective rather than a compliance one, for why governance decisions are engineering decisions, and why teams that defer them pay more for the same outcome — in incident response time, audit friction, and trust that is harder to rebuild.

Secure Systems

Logging Is a Security Control, Not Only a Debugging Tool

Logging is usually introduced into a system to help engineers debug — and then, quietly, it becomes the thing an incident response or an audit depends on entirely. Treating logging only as a debugging convenience means it is designed for the wrong audience: verbose enough to help a developer trace a bug, but not structured enough to answer the questions a security review actually asks, such as who accessed a resource, when, and what changed as a result. Designing logging as a security control from the start means deciding in advance what a security-relevant event looks like, making logs tamper-evident, and keeping them readable months later by someone who was not there when the code was written. This article looks at the practical difference between debug-oriented logging and security-oriented logging, and why systems operating in regulated or sensitive environments need to treat the two as related but distinct responsibilities.

ISO 27001/27002

From Policy Documents to Executable Security Practices

A well-written security policy document and a security practice that engineers actually follow are two different achievements, and the gap between them is where most governance programs quietly fail. A policy that says access should follow least privilege does not become true until someone translates it into a concrete process: who approves an access request, how quickly access is revoked when a role changes, and how that process is checked rather than assumed to be happening. Making a policy executable means turning its intent into specific, testable steps that fit into how a team already works, rather than adding a parallel process engineers route around under deadline pressure. Drawing on experience carrying information security responsibilities alongside hands-on engineering work, this article looks at how to take common policy themes — access control, change management, incident response — and translate them into practices a team can actually run, check, and improve.

Open to professional discussions and selected collaborations.

Get in touch