Navigating Liability in The Age of AI

When undertaking projects with clients, several issues happen and liability describes in detail who takes responsibility for what in the relationship.

Often, this means incredibly detailed contracts with points and sub-clauses for everything you can imagine, and of course, it just protects both parties in case of legal proceedings.

This gets trickier though when AI gets into the nuts and bolts of what humans are responsible for and how we do it safely and responsibly so all guidelines are met and exceeded.

While software can be used to lessen the overall risk, it cannot ultimately be liable for its output, whether or not it is AI, as the software engineers behind it legally are not allowed to be responsible for another discipline's engineering designs for example.

The proper offload of risk into software

It's hard to tell what the proper level of risk offload is sometimes and that's where software engineers come into play to ask questions and teach about what is possible.

When I provide solutions to clients, I ensure it is turnkey and well-certified against any expectations and regulations clients would have in the area.

That said, the design and project scope will be adjusted in a way so that if details between multiple blueprints need to be verified, for example, I surface those details to the user so cross-referencing becomes easy.

They'll still be responsible for understanding and confirming what the program has produced, but automation and AI have made the job easier as needed.

Do things that don't scale, until you can't

Paul Graham's essay "Do Things that Don't Scale" is the epitome of navigating the challenges of working a larval startup and even growing the business into its potential.

This essay shows how business is a series of constraints and how we release each constraint one by one to grow it into what it can be.

Getting to a point here, one side of liability is humans doing everything by hand which is too risky because we only have so much time and energy and we'll make a number of mistakes that will ultimately cost us in the long run.

Software will save us from the hours of monotony, but we ensure proper checks and balances are built in from project inception to delivery and growth.

This will allow the business to take flight and keep hands on more important work.

But you can automate too much

Lack of transparency into the results of software can be troublesome when a business needs a refined, repeatable process.

Too much automation comes into play when the cost of additional functionality becomes downright absurd compared to the size of the problem.

It also comes into play when the output of the program doesn't meet strict quality guidelines or ventures off into some tangential area that makes no sense.

In either case, we've gone too far with the automation of the software and need to back up a tad to ensure we meet proper design and regulatory standards.

For a concrete example, think about how LLMs hallucinate and give bogus output.

While there are economies of scale, too much information trapped within the weights will give you garbage output which is a sign of information overload within the model.

Getting it just right

For clients, we make sure we don't leave any value on the table when it comes to level of automation.

Think of AI this way, traditional software engineering gets us 50-60% of the way to automating the end-to-end process and AI allows us 90-100% automation with proper human checks put into the software.

Even though we can automate fully and compound on top of each other, it has to be done right or we'll be looking at a shaky house.

Done right, we can build amazing things together!