The future got here a while ago. But thanks to IBM’s Watson, we can’t ignore it any more.

Some background: IBM is turning Watson into a diagnostic support tool. The FDA wants to treat it as a medical device. IBM disputes that categorization and is spending sums that are, shall we say, significant lobbying to avoid this regulatory roadblock.

Fortunately, KJR’s crack medical policy division has come up with a solution that should be satisfactory to all concerned.

IBM has created an AI diagnostician, and claims it isn’t a medical device? Fair enough. Force-fitting it into a medical-device regulatory framework is force-fitting a hexagonal peg into an elliptical hole.

But we don’t need new legislation to cover this. We already know how to certify diagnosticians. They complete medical school and have to pass tests covering each course in the curriculum. They then go through three years of residency before being allowed to hang out their shingle as a medical doctor.

Why should Watson be allowed to bypass any of this, just because it isn’t built out of flesh and blood? The solution is straightforward: Each Watson sold must first pass all medical school exams, then go through three years of as near a replica of actual medical residency as can be devised.

Problem solved. You’re welcome.

But of course, like most solutions to most problems, this solution raises new problems of its own.

Imagine you’re a physician, in a practice that’s acquired a Watson of its very own. Watson provides a diagnosis and recommends a treatment for one of your patients, and you disagree.

Now what?

You have two choices — allow Watson’s judgment to override your own, or override Watson’s judgment with your own.

And your patient later dies. Not only is your conscience torturing you, the absence of tort reform is torturing you with a malpractice action.

It doesn’t matter whether you followed Watson’s judgment or your own. You’ll be susceptible to the tort and torture whether you allowed Watson to override your good judgment, or you overrode Watson’s.

It’s Hobson’s choice. The question for medical ethicians is how to deal with this unresolvable question, and before they even start we know they’ll never come up with a fully satisfactory answer.

We can all thank our lucky stars we don’t have to deal with ethical questions this thorny.

Only, when we thank them we’ll be fooling ourselves, because we’re all dealing with this situation already. It’s the situation we face when our GPS gives us directions we don’t think make sense. We have to decide whether our GPS is routing us strangely because it knows more than we do about the traffic conditions ahead, or whether there’s a glitch in the algorithm and it’s pointing us in the wrong direction.

Not as ethically interesting? If you’re meeting someone for drinks after work, no it isn’t. But what if you’re driving someone to the hospital because they’re in intense pain and the cause might be grave?

It’s the physician and Watson, up close and personal, in real time.

It’s a question of who or what’s in charge, human beings or information technology. It’s a question with a simple answer: Humans, of course, both because we program the computers and because we’re ultimately responsible for the decisions, too.

Except that answer doesn’t always work. A computer-controlled traffic light is an easy-to-understand and inarguable example, because overriding the computer’s recommended course of action (stop before entering the intersection) isn’t merely a violation of traffic laws. It’s a decision with potentially lethal consequences.

When it comes to traffic lights we obey the machine.

The world of commerce is hardly immune from these challenges, starting with the requirement that humans are sometimes required to obey computers here, too. That’s what you face if you work in a call center. A computer (the ACD — automated call distributor) directs a call to your phone. What do you do? You answer it. You, the human, obey the ACD, a computer.

Or, you’re a manager, responsible for a decision that could be influenced by some form of automated support, whether it’s an old-fashioned Decision Support System, a no-longer-fashionable data warehouse, or ultrafashionable Hadoop-driven big-data analytics.

If the analytics indicate a course of action that doesn’t seem right to you, how is that different from the physician deciding about Watson’s diagnosis and recommended treatment?

There are no answers that are both easy and useful, and the questions are becoming more pressing as each day goes by.

Your phone is ringing. It’s the future, calling to let you know it just got into town and would like to meet you for drinks.

Time to get out the GPS.

This time it’s Anthem.

The good news about Anthem’s loss of 80 million customer records is that no personal health information was stolen. Were I an Anthem customer, I’m quite sure I’d be thinking to myself, “All the thieves can do is steal my identity. Thank heavens they didn’t find out what I’m allergic to!”

Look forward to the usual rehashing of what Anthem should and shouldn’t have done. KJR won’t pile on, because there’s really no point.

Forget that. Of course KJR will pile on because really, how am I supposed to resist the temptation?

And so:

In Anthem’s official statement on the subject its CEO, Joseph Swedish, described what happened as a “… highly sophisticated external data attack.” Some aspects of the attack probably were highly sophisticated. But it also turns out the stolen “personally identifiable information” (PII), including customers’ social security numbers, was not encrypted in Anthem’s databases.

While I’ve never claimed to be an authority in information security, I know enough to give this advice: Don’t make it easy.

This is why you lock your car. It won’t stymie a professional car thief. It will, however, keep it out of the hands of amateur joy-riders while making stealing someone else’s car the easier choice for the professionals, and, by the way, satisfy your insurance company.

Anthem’s defenders point out that, like many other companies, it has to connect its customers’ data to data in external sources, and especially data in government databases. The social security number is the only choice for JOINing data about individuals when you don’t control the data design.

To encrypt it or not to encrypt it, that is the question.

No, I won’t go all Hamlet on you. Here there’s only one answer: Encrypt.

At this stage of the game, there really is no excuse for any company to use social security numbers as the primary identification key for customer and employee records. Assigning a sequential or randomly-generated identification number when first creating a customer master record is routine. It isn’t “best practice.” It’s the minimum standard of basic professionalism.

This way, JOINing records from internal databases doesn’t have to rely on social security numbers, so the inconvenience and difficulties associated with encrypting social security numbers, as pointed out in a Wall Street Journal story on the subject, doesn’t apply to processing that involves no external data.

But medical information doesn’t stay within any single corporation. For both treatment and payment purposes, medical records, including insurance information, has to be shared externally, and right now the social security number is, in the United States, the single universal identification key.

Whether used by an insurance company to add external information to its internal records for analytics purposes, or used by healthcare providers to link medical records from multiple sources so as to improve treatment, at some point in the proceedings, unencrypted social security numbers have to make an appearance.

Security professionals, along with those of us who like to pretend to more sophistication in the field than we actually have, differentiate data in motion from data at rest. Anthem encrypted its data in motion but not its data at rest, on the theory that hardening its perimeter constituted sufficient protection of its information assets.

This gets it exactly backward. For several years now it’s been understood by security professionals that just about every major trend affecting systems and information access, but in particular the rise of the cloud, more off-premises computing, and the increasing reliance of cyber-attackers on phishing attacks and Trojan horses, all result in a decrease in effectiveness of perimeter hardening and an increase in the importance of hardening assets.

When it comes to hardening information assets, encryption might not be the whole story but it certainly is the starting point. And JOINing two tables based on encrypted social security numbers isn’t all that hard. Properly authorized individuals can be given access to the decryption function, through which they can create temporary tables that have unencrypted social security numbers. They can use these tables for whatever analysis they like, destroying them as soon as they’re finished with them.

But hard, I’ll bet, isn’t the issue. Here’s what is: Converting decades of accumulated reports, queries and other computing flotsam and jetsam, combined with organizational habits built up over the same span of decades, that all rely on having access to unencrypted PII.

Tracking them all down and replacing them with more-secure alternatives would cost a lot of time and money, with an unmeasurable payoff. It’s a risk management issue mentioned in this space from time to time: Successful prevention is indistinguishable from absence of risk.

Sadly for the Anthems of the world, failed prevention is not.